avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Optional Dependencies
Date Wed, 10 Jul 2002 14:01:09 GMT
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net] 
> 
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > 
> > > From: Peter Donald [mailto:peter@apache.org]
> > >
> > > 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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message