Vadim
--
Resistance is futile.
> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 10, 2002 10:01 AM
> To: 'Avalon Developers List'
> Subject: RE: Optional Dependencies
>
> > 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.
Ideally, yes, of course.
> 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.
It depends on concrete store implementation semantics. Memory store does
not has persistence, filesystem store got only persistence, mru is
combination, etc.
> 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.
It is easier, I do agree, perfect world will have only thread safe
components, PhD-s as designers, and people who know what is hexadecimal
numbers are as coders.
But all this is beside the point. My point is that this (decision
"stores are threadsafe") must be either enforced (by store interface
extending threadsafe) or *very* good documented, so no stupid (but
educated enough to RTFM) soul could implement Recyclable store.
Vadim
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
