RE: [picocontainer-dev] Storing Cached items in HttpSession?

Paul Hammant wrote on Monday, August 13, 2007 8:56 AM:

>> +1. The Pico should pick up the deps in the session automatically
>> without being stored itself. There's just one thing left: How will
>> you support the lifecycle i.e. how do you know that a component has
>> been started/stopped ... ?
> 
> Just committed - http://svn.picocontainer.codehaus.org/changelog/
> picocontainer/?cs=3822 
> 
> Take a look at the last test method in StoreCachingTestCase.  It
> simulates what a web framework would do.  For each HttpRequest, the
> Map of keys to instances would be retrieved from the HttpSession and
> set for the thread. If there is nothing there for the
> HttpSession, it
> must be new and the Cache values will be missing.

I think StoredCached uses a wrong implementation. Basically the ObjectReference should be responsible for keeping the object. Like in the ThreadCached impl, the StoreCached impl should be only a convenience class:

class StoreCached {
	private final Map map = new HashMap();
	StoreCached(final CA delegate) {
		super(delegate, new ObjectRererence() {
			Object get() {
				return map.get(getComponentKey());
			}
			Object put(Object obj) {
				map.gut(getComponentKey(), obj);
			}
		});
	}
}

All implemented with anon classes, but I hope you see the point (and no need for "protected" members in "Cached").

BTW: I'd really like to have a references package for all the ObjectReference impls (boy, how I miss ObjectReference in the JDK itself. Could have used it so often already).

> There are two things I think need to be done
> 
> 1) make data private so that anyone else retrieving the map from the
> HttpSession will not be able to access data.
> 
> 2) worry about whether synchronized needs to be applied.  Browsers
> can issue more that one request for the same session simultaneously.
> There could be contention on populating the map ? Maybe ?

In the impl above synchronization is the task of the map impl.
 
> So on the question - "what about startable?"  Yeah needs some
> thought.  StoreCached extends Cached which understands some lifecycle
> stuff. There are a number of ideas that could be coded.

The impl above inherits the behaviour from Cached.
 
> And lastly, I have naming blues for StoreCaching and StoreCached.
> Suggestions anyone ? 

Above they are more "ExternallyManaged"  ;-)

- Jörg

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email