Dan said,
> Is sharing of the http sesssion state standard for all Servlet 2.2
> compliant web
> containers? I can't imagine that it would not be?
>
Not across multiple JVMs. Standard http session state management is per
servlet engine. Only GemStone/J can really can share session state
transparently across JVM's.
> The data cache idea is a good one. I would prefer a solution that works
> in any
> vendors ejb server. The cache is really just another data source.
>
That's correct. And it's important that it be an XA data source at that so
that transaction between your cache and backend data stores are atomic.
> Is there any
> standard way to do this?
>
It's standards based (JNDI, CORBA OTS, XA 2PC...), but only GemStone/J
brings it together in one package. You can probably get there with third
party containers such as Javlin, so its not like you don't have anywhere to
go.
> dan
>
> Chris Raber wrote:
>
> > Dan,
> >
> > <vendor>
> > GemStone/J provides some good solutions in this area, including:
> >
> > - Shared http session state. GemStone/J can share http session state
> across
> > multiple JVM's and server machines. You code to standard http session
> state
> > apis (nothing proprietary). We share the session state map through PCA
> > transaparently.
> >
> > - You can use PCA directly to cache things. PCA is accessed through JNDI
> > (very transparent to your object model). Concurrency services and
> multiple
> > read/writer collisions. This is similar to ObjectDesign's offering, but
> all
> > bundled into the EJB server itself.
> > </vendor>
> >
> > -Chris.
> >
> > http://www.gemstone.com/
> >
> > > -----Original Message-----
> > > From: dan benanav [SMTP:[EMAIL PROTECTED]]
> > > Sent: Tuesday, January 18, 2000 7:44 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Caching of read-only DB contents in an EJB
> > >
> > > 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!
> > >
> > > 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".
> > >
> >
> >
> ==========================================================================
> =
> > 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".
