At my last company, we implemented a transactional distributed cache (very similar to the features mentioned in this thread) in about 5 or 6 man years (7 months wall time). Definitely not a month, but a far cry from 15 years! :-)
Erik
--
Erik Huddleston, [EMAIL PROTECTED]
Chief Architect, eCustomers.com
Microsoft Java MVP
> -----Original Message-----
> From: Chris Raber [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 19, 2000 11:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
>
> 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".
