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

Hi Paul,

there are some commonts in between, but some of them get obsolete by my last comment - after I put some thought into it.

Paul Hammant wrote on Monday, August 13, 2007 10:16 PM:

>> 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);
>> 			}
>> 		});
>> 	}
>> }
> 
> Done as you say, but with the anon inner class in StoredCaching (the
> factory). 

Fine. Now, is StoreCached the right name anymore? My impl did not make any assumptions about threads, while the current one now keep the map  in a TL. IMHO Store & Cache are quite similar .. maybe you should cal this simply ThreadStore.

>> All implemented with anon classes, but I hope you see the point
>> (and no need for "protected" members in "Cached").
>> 
> 
> .. protected chg undone.
> 
>> 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).
>> 
> 
> Yeah, there are a few, Mosly named inner classes.  Will have a look.

That would be great. Such a pity that the interface is not more official. I've seen that interface with several impls now in different frameworks.

[snip]

>> The impl above inherits the behaviour from Cached.
> 
> Now it just uses Cached as is.  StoreCached the class has
> been deleted.

OK. I've fixed the impl. You derived StoreWrapper from TL and I thoink this was a simple C&P error. Additionally StoreWrapper is now a Serializable (which is a necessity for the web app and TL is not serializable by definition anyway).

========== After some thoughts ======

However, I am curious how we use this impl now in nanowar. Jake's problem was the Session-Pico and (Request-Pico). Since they build a hierarchy, you cannot but the session Pico into the session without having an implicit reference to the parent. With the current impl we try to solve the problem ... but now you do not know, how you can retrieve and put back the StoreWrapper! Therefore I believe the impl is still not right. The store must be retrieved automatically from the session to get this working. Funny thing is: We have that already! It's the SessionReference!

Therefore I'd propose to drop the StoreThreadLocal at all. Keep the Map in an ordinary ObjectReference<Map> provided by the ctor. This means you may use the SessionReference within nanowar (or a specialized version that keeps the Map into an unaccessible wrapper). Additionally you don't have (resp. you don't have to expose) a superfluous type like StoreWrapper and can omit this ugly getter/setter in the StoreCaching (may be Storing only now ?). With such a setup you can recreate your pico hierarchy in nanowar easily and the cached instances are automatically used from the session - and that's what we tried to do, isn't it? ;-)

- Jörg

BTW: The current unit tests should still work with such an impl by providing a ThreadLocalObjectReference (currently located in gems).

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

    http://xircles.codehaus.org/manage_email