Pooling vs Instance Caches

[Anurag Mishra]

Hi,
my Question is related with Stateless n Stateful Session Beans.
1. in Stateless Session Beans we use Pool of Stateless Session Bean.
BUT
2. In Stateful Session Beans there is No Pooling, we use Caches.
So what is the difference b/w Pooling and Caching ?
thanks in advance.

[Lasse Koskela]

1. in Stateless Session Beans we use Pool of Stateless Session Bean.
BUT
2. In Stateful Session Beans there is No Pooling, we use Caches.
So what is the difference b/w Pooling and Caching ?

I would be interested to hear about where did you learn that stateful session beans are cached?
Stateless session beans are pooled: there's a limited number of beans in a pool and the container picks instances from the pool to serve requests as they come. Whether stateful session beans are pooled is a whole different beast -- it's really up to the container implementation to decide whether they'll get anything out of pooling something related to stateful session beans.

As a side note, take a look at here...
[ August 12, 2003: Message edited by: Lasse Koskela ]

[Pradeep bhatt]

I would say that caching is some temporary storing of data to avoid the costly retrieval of data from some storage say database.

Pooling is to avoid the costly creation of objects, objects will are reusable. For e.g. SLSB, database connection.
Any one having different ideas?

[Lasse Koskela]

I would say that caching is some temporary storing of data to avoid the costly retrieval of data from some storage say database.

Aaa. The caching could have meant the fact that the in-use (or "not free") SFSB instances are being held in memory (cached) and only passivated to disk when the container deems necessary.

[Pradeep bhatt]

What about entity beans ? I would not call stateful session beans as cache but certainly entity beans?

[Lasse Koskela]

What about entity beans ? I would not call stateful session beans as cache but certainly entity beans?

A good CMP implementation does provide a caching layer behind the curtains.

[Anurag Mishra]

Hi thanks a lot,
but still i m not clear about Sateful Session Bean is there something called Caching is used or not??
As---->
1. EJB Specification does not allow pooling of StateFulSessionBean.
2. But most of the AppServer uses Instance caches.
so what is diff in terms of Pooling for StateLess Session Beans
and Instance Caching of StateFul Session Beans.

Lasse regardin Naming convention my Public Name is correct so why were u pointed me to that page?
thanks
Anurag

[Lasse Koskela]

but still i m not clear about Sateful Session Bean is there something called Caching is used or not??
As---->
1. EJB Specification does not allow pooling of StateFulSessionBean.
2. But most of the AppServer uses Instance caches.
so what is diff in terms of Pooling for StateLess Session Beans
and Instance Caching of StateFul Session Beans.

Stateless session beans can be pooled as a whole because they are homogeneous -- you can't tell one SLSB from another and it's totally irrelevant which particular instance serves which particular method invocation request. Furthermore, it doesn't make sense to passivate stateless session beans to disk because they don't have any state. This is clear, isn't it?
So, stateful session beans and instance caching... Let's take a scenario where the application server is pooling the beans. Once a client creates a stateful session bean, one of the instances of the "MyStatefulSessionBean_impl" class is picked from an anonymous pool and given a state. The client invokes a couple of methods (modifying the bean's state) and goes out for lunch. Assume these steps are performed by thousand different clients simultaneously. Now the container has 1000 instances of the stateful session bean, each with a different state. The container might keep all these beans and their state in memory, or it could persist the state onto the disk until their respective client comes back from lunch. The container could rip the state off of the bean itself, write it into a file, and return the bean into the "pool". When a client comes back from lunch and tries to use her EJB reference to a bean that was passivated this way, the container takes a bean from the pool, reads the client's state from disk into the bean, and delegates the method calls as usual. This is how stateful session beans can be pooled. Another question is whether this brings any performance benefits over passivating the whole bean along with its state. I guess this is why it's usually said that stateful session beans can't be/aren't pooled. This is also what I think people have meant by "instance pooling" -- the bean instances are pooled and the state is managed separately.

Lasse regardin Naming convention my Public Name is correct so why were u pointed me to that page?

To me "Anurag_M" visible in your posts doesn't seem to follow the required "firstname lastname" format.

[Anurag Mishra]

thanks a lot.
i have changed my Display name according to naming policy now its Anurag M.

[Karthik Guru]

Some questions on entity bean cache. When we mention "caching" do we mean that the implementation might cache the results of a finder for eg?
or say a ejbCreate might not actually persist data immidiately but postpone the action?.
Is there a probablility of the server memory getting clogged with bean instances and as a result make the entire app slow? W'd caching cause a problem when the same database is being used by different applications? / even simpler, if I use a different mechanism (pure JDBC, assumign that any practical EJB solution w'd, in all probablity have a bean and a faster non-ejb approach bundled together ) to get in some data into the database?, do we expect the finder to return some cached data and not do a look up again since some of the data never went thro' the EJB layer in the first place? I mean in general, is switching caching on/off a tricky thing?
Moreover, if there are practical experiences (wrt tuning the cache) that somebody can share , it w'd make my day.

[Pradeep bhatt]

The entity bean represent the in memory representation of data in database.
Retrieving from memory is much faster.
The EJB container may not persist data unless the transaction is commited. Any other thoughts?
Finder methods do not return cached data. I dunno what do you mean by tuning cache?

[Lasse Koskela]

When we mention "caching" do we mean that the implementation might cache the results of a finder for eg?

As Pradeep already mentioned, entity bean caching means that the data model is being held in memory as a write-through cache. When something gets updated, the cache is refreshed for that part.

Is there a probablility of the server memory getting clogged with bean instances and as a result make the entire app slow?

Yes there is, that's why the container will passivate entity beans as needed.

W'd caching cause a problem when the same database is being used by different applications? / even simpler, if I use a different mechanism (pure JDBC, assumign that any practical EJB solution w'd, in all probablity have a bean and a faster non-ejb approach bundled together ) to get in some data into the database?, do we expect the finder to return some cached data and not do a look up again since some of the data never went thro' the EJB layer in the first place? I mean in general, is switching caching on/off a tricky thing?

If you have two applications using the same database and the other application has some cached data, it will not get any notice from the database when the other application inserts something. The same applies within a single application. If you have an entity bean layer and use JDBC to write stuff into the same tables, the database will not inform the entity bean layer about the changes. It's still safe to use JDBC for big read-only operations (e.g. search against a huge database of articles) but you better not use JDBC to manage the same database tables as your entity bean layer is using.

[Karthik Guru]

>> When something gets updated, the cache is refreshed for that part.
ie if that bean is present in the container cache to start with. ok?
>> but you better not use JDBC to manage the same database tables as
>> your entity bean layer is using.
oh so you are saying that we s'dnt be having an Entity bean mapping to such tables in the first place? I might have some entities that have some kind of relationship with those tables. Kind of wonder if persisting them w'd actually mean using jdbc and CMP at the same time :-(

>> The entity bean represent the in memory representation of data in
>> database.
For some of the data, yes. But i wonder how the container decides what to cache and otherwise. I mean i have a table that represents many entities, all of them are equal and w'dnt we want to be choosy when it comes to caching something?
>> Retrieving from memory is much faster.
that's fine.

[Karthik Guru]

I dunno what do you mean by tuning cache?
I was referring to this:
http://edocs.bea.com/wls/docs70/programming/app_xml.html

[Chris Mathews]

Originally posted by karthik Guru:
oh so you are saying that we s'dnt be having an Entity bean mapping to such tables in the first place? I might have some entities that have some kind of relationship with those tables. Kind of wonder if persisting them w'd actually mean using jdbc and CMP at the same time :-(

What Lasse is saying is that if you have the Application Server caching Entities Bean and you go behind its back and change the underlying value (via straight JDBC or whatever) then you are in for trouble. If you are employing a heavy caching approach then all changes must go thru the Entity Bean layer in order to maintain data integrity.
Proper caching can really help increase performance for database intensive applications. However, one disappointing thing to remember is that most Application Servers do not offer distributing caching capabilities out of the box. Therefore, you won't be able to employ effective caching in the Entity Bean layer if your application is clustered without ponying up some cash for third-party tools.
[ August 13, 2003: Message edited by: Chris Mathews ]

[Karthik Guru]

Originally posted by Chris Mathews:

What Lasse is saying is that if you have the Application Server caching Entities Bean and you go behind its back and change the underlying value (via straight JDBC or whatever) then you are in for trouble. If you are employing a heavy caching approach then all changes must go thru the Entity Bean layer in order to maintain data integrity.
[ August 13, 2003: Message edited by: Chris Mathews ]

Yes I understand that.
This is my concern though..
The way we might have large read only operations on a table ( where we can use JDBC) , we might have large inserts as well into the same table. Using ejbCreate for such huge entries w'd obviosuly take ages to get the data in.
So my question is that since the table might be read / written to (both might involve huge reads/writes), s'd we not have an entity bean at all to model that table?
Hence the follow up question that
if i have another entity bean that has some kind of relationship with those tables, i w'd end up with a CMP bean create and JDBC code @ the same time.
Yeah perfectly achieveable..but for some reason i found that a little dirty.
..

[Chris Mathews]

Originally posted by karthik Guru:
The way we might have large read only operations on a table ( where we can use JDBC) , we might have large inserts as well into the same table. Using ejbCreate for such huge entries w'd obviosuly take ages to get the data in.

I am not convinced that using an Entity Bean to insert data into a table is such a slow process compared to straight JDBC, not that I am a big fan of Entity Beans or anything. I am curious as to why you think this. The inserts will still need to take place one at a time, even if you are using plain JDBC (there is no standard SQL Statement to perform bulk inserts).

Originally posted by karthik Guru:
So my question is that since the table might be read / written to (both might involve huge reads/writes), s'd we not have an entity bean at all to model that table?
Hence the follow up question that
if i have another entity bean that has some kind of relationship with those tables, i w'd end up with a CMP bean create and JDBC code @ the same time.
Yeah perfectly achieveable..but for some reason i found that a little dirty.
..

You could still model the table as an Entity Bean and have it participate in CMR relationship with the rest of your model. Just make sure that the Application Server is not trying to cache data for that particular Entity Bean (since you know the data can change behind the scenes).
You may be interested in participating in this thread also.
[ August 13, 2003: Message edited by: Chris Mathews ]