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?
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. Is there any
standard way to do this?
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".
