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