Precisely.
arkin
Chris Raber wrote:
>
> What is the ultimate goal? To provide an open source J2EE implementation?
>
> Regards,
>
> -Chris.
>
> > -----Original Message-----
> > From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, January 20, 2000 3:09 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Caching of read-only DB contents in an EJB
> >
> > Chris Raber wrote:
> > >
> > > 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 ;-)
> >
> > I can give you the code if you want to take a look.
> >
> > XA two phase commit is working, locking is working (read/write),
> > deadlock detection is working, collections will be available in the next
> > release.
> >
> > The current design is not distributed at all (never said it was), since
> > it was based on RDBMS persistence engine which used the RDBMS for
> > distributed locking. But we're getting a contribution of a distributed
> > design which will take care of distributed locking and garbage
> > collection.
> >
> > arkin
> >
> >
> > >
> > > -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".
> >
> > --
> > ----------------------------------------------------------------------
> > 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".
