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".
