Assaf,
You just described GemStone/J's PCA "to a tee".
-Chris.
> -----Original Message-----
> From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 18, 2000 9:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> Totally different approach and hopefully I understood your requirements
> right:
>
> A CMP-like mechanism that instead persisting the objects to the database
> engine, simply keeps them in memory accessible at all times. Entity bean
> semantics apply when dealing with the object. The only difference
> between that and using BMP entity beans is the locking and rollback that
> the CMP engine takes care of.
>
> Such an engine would allow you to share the same copy of an object, get
> a working copy each time you use it, get read/write locks, track
> deadlocks, and if a rollback occurs it will revert the object to its
> original state. It's will be integrated into the server through
> XAResource, so the EJB transaction semantics govern it (i.e.
> commit/rollback occur automatically).
>
> Is that what you were looking for?
>
> arkin
>
>
> Dan Benanav wrote:
> >
> > see inline comments.
> >
> > dan benanav wrote:
> >
> > > I am very interested in caching and have been asking a similar
> > > question in another subject thread. See Re: Thread Safety, Session
> > > beans,Saving in servlet sessions.
> > >
> > > Often in web based applications session state for clients must be
> > > maintained. Essentially this is just a cache for data. The
> > > requirements are:
> > >
> > > 1) The cache may be accessed concurrently by multiple threads doing
> > > both reading and writing. (Even if you use an HttpSession there is
> > > no guarantee that only one thread will access the cache at a time.)
> > > 2) Exclusive locks should be obtained for writing.
> > > 3) Shared locks for reading or perhaps exclusive locks would be OK.
> > >
> > > The Sun Blueprints guideline suggests using a session bean for this
> > > which is stored in an HttpSession object. However that doesn't work
> > > because session beans (stateless or stateful) don't allow for
> > > concurrent access. Synchronizing calls in the Servlet won't work in
> > > a clustered servlet environment.
> > >
> > > I thought that perhaps one could use an entity bean which references
> > > a stateless session bean. But I have a question about this. The
> > > specification states that a container can create multiple bean
> > > instances to handle method calls in separate transactions. So
> > > suppose the following occurs,
> > >
> > > 1) Under transaction A, method foo is called. The container
> > > delegates this call to the foo method of entity bean instance B1.
> > > This method accesses the foo method of a stateless session bean.
> > > 2) Under transaction B, method foo is called. The container
> > > delegates this call to the foo method of entity bean instance B2.
> > > This method accesses the foo method of a stateless session bean.
> > >
> > > Since transaction A and B are occurring in separate thread it is
> > > possible that the foo method is called concurrently on the stateless
> > > session bean or beans. Since concurrent access is not allowed on
> > > session beans B1 and B2 should not be storing a handle to the
> > > stateless bean and should instead called create to access the
> > > stateless bean. This means that that cache would have to bean
> > > stored in a static variable of the stateless bean. But that is not
> > > thread safe. Hence the entity bean calling the stateless session
> > > bean will not work!
> > >
> >
> > I meant to use stateful session beans for the above. But all the
> > arguments still hold. Stateless could be used for a general cache not
> > associated with a client.
> >
> > >
> > > Now I am asking myself the following questions.
> > >
> > > 1) Why use a session bean at all for storing Http session
> > > information? Maybe just use the HttpSession object and synchronize
> > > it's methods. The Web container will have to ensure that multiple
> > > servlet instances all reference the same HttpSession object. If
> > > this is the conclusion then this means session beans don't work for
> > > storing Http session state and the programmer will have to write
> > > multi-thread safe code.
> > >
> > > 2) Still wondering how to properly write a cache with multiple
> > > readers and writers that is access from entity or session beans.
> > > Using entity beans to cache will not because a container could
> > > create multiple copies of the bean and there is no way to
> > > synchronize the multiple copies. So the only remaining option as
> > > mentioned by Rickard is to use RMI. Anyone have information on
> > > how to do that? What about transactions handling etc..? One other
> > > choice is to use the Javlin product from ObjectDesign. Has anyone
> > > used that?
> > >
> > > dan
> > >
> > > Rickard �berg wrote:
> > >
> > >> Hi!
> > >>
> > >> "Lahooti, Hamid" wrote:
> > >> > >>Almost but not quite. Readonly data can be cached by stateless
> > >> session
> > >> > >>beans. If you need read/write caching then either use Entities
> > >> or a RMI
> > >> > >>object.
> > >> >
> > >> > A stateless session bean with a state?
> > >>
> > >> Yes. If it's readonly and not client specific. Sure.
> > >>
> > >> > as a singleton?
> > >>
> > >> I didn't say that.
> > >>
> > >> > and it
> > >> > doesn't get destroyed by the container?
> > >>
> > >> The state may be kept in instance variables of each stateless
> > >> session
> > >> bean instance, or if you want to optimize it you could store it in
> > >>
> > >> static variables and use lazy loading (i.e. check on each usage
> > >> that the
> > >> class has not been reset, in which case you load the data again).
> > >>
> > >> /Rickard
> > >>
> > >> --
> > >> Rickard �berg
> > >>
> > >> @home: +46 13 177937
> > >> Email: [EMAIL PROTECTED]
> > >> http://www.dreambean.com
> > >> Question reality
> > >>
> > >> ================
> > >> ==========================================================
> > >> To unsubscribe, send email to [EMAIL PROTECTED] and include in
> > >> the body
> > >> of the message "signoff EJB-INTEREST". For general help, send
> > >> email to
> > >> [EMAIL PROTECTED] and include in the body of the message
> > >> "help".
> > >
>
> --
> ----------------------------------------------------------------------
> Assaf Arkin www.exoffice.com
> CTO, Exoffice Technologies, Inc. www.exolab.org
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
