Re: [picocontainer-dev] [pico2] CachingBehavior + multiple instances..
Paul Hammant <[email protected]>
| Newsgroups | gmane.comp.java.picocontainer.devel |
|---|---|
| Message-ID | <[email protected]> |
(Pete and I were pairing over beer last night) The issue is that in Pico2, CachingBehaviorFactory delegates to SyncrohizedBehaviorFactory delegates to ConstuctorInjectionFactory which is wrong cos SyncrohizedBehaviorFactory should be frontmost to prevent cache problems. The question is, should CachingBehaviorFactory be synchronized itself , or is there a situation you'd use caching w/o synchronized or vice versa? Say more on ReentrantReadWriteLock ... I've not used it. - Paul On Jun 20, 2007, at 11:36 PM, Jörg Schaible wrote: > Hi Peter, > >> -----Original Message----- >> From: peter royal [mailto:[email protected]] >> Sent: Thursday, June 21, 2007 4:38 AM >> To: dev-qxt/[email protected] >> Subject: [picocontainer-dev] [pico2] CachingBehavior + >> multiple instances.. >> >> in pico1-world, when using the CachingCAF, it means that you only >> want a single instance of the component. >> >> with lazy instantiation, this means that if the component has no >> lifecycle, and if multiple threads ask for the component, you >> may get >> discrete instances (last one wins wrt the cache). > > Therefore we also had the SynchronizedCAF ... although not active > by default. But in such a scenario the default CAF of the container > should have been replaced with a CAF chain containing the > synchronization. > >> currently, in pico2, there are two behaviors, a >> CachingBehavior and a >> SynchronizedBehavior.. SyncBehavior being simple, just wrapping >> another behavior and synchronizing getComponent. idea being >> you could >> use these to to achieve the intent of the pico1 behavior.. >> >> thought is that if you are using the CachingBehavior, you >> only want a >> single instance at that point in the chain, and it should >> ensure that >> it only ever creates a single instance.. thus the >> SyncBehavior can go >> away. >> >> thoughts? (lazy consensus)! > > At least we can use with JDK 5 a ReentrantReadWriteLock that > provides optimal performance reading and writing. > > - Jörg > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email