Dan,
More follow up.
Dan wrote:
> -----Original Message-----
> The container managed persistence mechanism sounds pretty good however
> there are
> a couple of questions/issues I have.
>
> 1. Suppose you wanted to persist a complicated structure like a graph.
> How
> would you do that in you approach? There may be various operations that
> you
> perform on the graph, like adding an edge, removing and edge, adding nodes
> etc.. For efficiency the entire graph should be cached.
>
This is exactly what GemStone/J does. Objects are cached as objects. No
datasource mapping is required...
> 2. The container managed approach is not really standard. It wouldn't
> work
> with any EJB Server would it?
>
There are proprietary aspects here, but you can isolate yourself from them
pretty easily. By hiding this all behind a CMP implementation we can do this
in a vendor neutral manner.
> What if instead of CMP an object database that stores all information in
> memory
> is used. Instead of it exclusively being container managed allow for bean
> managed as well.
>
That is basically what GemStone/J's cache is!
> Then an entity bean would be able to get a connection to the object
> database and
> retrieve various objects and call methods on those objects. So in other
> words it
> would be similar to the use of a relational database which permits either
> bean
> managed or container managed persistence.
>
Yes yes yes.
> Essentially what I am looking for is something that would plug into any
> EJB
> Server and something that can handle arbitrarily complicated structures
> (Like a
> very large graph).
>
We provide the EJB server an the object persistence capability in one
package. You could use another EJB server on top of GemStone/J if you
wanted, but it would be silly to.
> 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".
>
> ==========================================================================
> =
> 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".
