> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > > > From: Peter Donald [mailto:[EMAIL PROTECTED]] > > > > > > I looked at all the store implementations and they all were > > > threadsafe and I applied the same logic as I did wrt the > > > XMLizer/Parser. ie If all implementations are threadsafe > then dont > > > worry about releasing the component. > > > > > > If the component was poolable then what I did would not > be good - it > > > would suck actually ;) > > > > > > :) > > > > Think of the design practicality. If a store were > poolable, you have > > no guarantee of getting a hold of the store that has the object you > > placed in it again. You would be SOL. > > With the exception of SQL store, XML:DB store, filesystem store, FTP > store, etc.
I would hope that your goal is to write components that are either threadsafe, or can supply implementations that are threadsafe. Precluding that ability in the interface (like Cocoon's fatal flaw) really forces the container to eat up resources unnecessarily. The Store interface has no guarantee of persistence, even more importantly there is no guarantee of immediate persistence. If your object is eventually stored in a database, an intelligently designed store object will hold on to it in memory until the load on a machine goes down. Having multiple instances of a store object when the storage is persistent has the additional overhead of thread monitoring for the resources because they have to manage the independent calls on the external resource between several instances of the same component. It's a whole lot easier to manage that in one instance because your synchronization mechanisms are managed internally instead of externally. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
