Erik,
To be clear, 15 years is the total life span of GemStone the company. The 15
years encompasses numerous releases of our legacy Smalltalk server and our
earlier "proprietary" java server.
The current J2EE server offering was released in fall of '98 after about a
year or so of wall clock development. The many years of experience that
preceded this version of our product were used to engineer it. Of course
some bits were borrowed too. Since then we have had another year in the
market to address quality and performance issues.
My point is that such and undertaking is a huge and risky endeavor. The fact
that you were successful at this at all is quite impressive. I would argue
that spending 5 or 6 man years to build these things yourself is a waste of
your energy (unless you are a server vendor). If you are trying to build
applications then that is where you should put your energy. Simple
economics, divide and conquer and all that. Then again perhaps such a thing
that meets your requirements was not available at the time... There is also
the cost of ownership (maintenance, upgrades, on-going improvement). The
market should be doing this for you.
Regards,
-Chris.
> -----Original Message-----
> From: Erik Huddleston [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 20, 2000 10:20 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> 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".
>
===========================================================================
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".
