Ok, well it only took us 15 years to build this stuff (first in Smalltalk
and now in Java for the second time). Oh by the way, we haven't discussed
distrubted garbage collection, concurrent update classes, scalable
collections, locking, concurrency, XA two phase commit transactions...
Assuming you have a combined IQ of GemStone's core engineering staff (who
probably average 150 each), maybe you can pull of the same thing in a month
or two ;-)
-Chris.
> -----Original Message-----
> From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 18, 2000 10:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> I know. I like it.
>
> It solves some of the problems we were running into in Servlet
> development without forcing us to use the database when we don't have
> to, and if we can get the engine to load balance, many problems are
> solved.
>
> <open source>
> We're going to release such an object cache mechanism which is an EJB
> resource and CMP engine in the coming month.
>
> License as usual is the BSD-like.
> </open source>
>
> arkin
>
>
> Chris Raber wrote:
> >
> > 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".
>
> --
> ----------------------------------------------------------------------
> 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".
