• Post Reply Bookmark Topic Watch Topic
  • New Topic

StateFul SessionBean Passivation  RSS feed

 
vijay ks
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am running a EJB application in weblogic, using StateFul SessionBean.Suppose say,
the maximum number of clients at a time is 100.(And assume that this is the maximum no of beans taht are created).Now 2 more clients 101,102 are coming.This time the 1st,2nd client are idle, so that their beans are passivated.Now What will happen,

1.Whether the container will create 2 more beans for the 101,102 client

or

2.the Clients shouold wait until, any 2 of the previously created clients going to logout

or

3.I read in EdRoman Book, the following,Excerpt
--------------------------------------------------------------------------------------------------
if a SF bean is passivated for a particular client.And the client again came the same bean is not necessarily to serve for that client.Any bean can activate and work for the client, from the point where the original bean is left.
--------------------------------------------------------------------------------------------------
If this is the case.
then the container will activate the 2 beans and give it to them(101, 102 ).And now the original client (that is 1, 2 clients ) agin they are invoking business method .Now they(1,2nd) should wait for any other 2 clients beans for passivation.
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vijay,

Since you�re using WebLogic is good to know that internally the container maintains a cache of SFSBs. You can also control the size of the cache using the max-bean-in-cache deployment descriptor. Knowing that is also good to know that for the case where the number of clients could be predictable, the best approach is to set max-bean-in-cache >= number_of_clients. Hence setting the cache to 102 should be the best solution to your problem.
However the container will also allow you controlling the algorithm for passivating the beans: LRU or NRU (defaults to NRU). With LRU you�ll get an eagerly passivation, which basically means that the bean is passivated after a certain amount of time (defined by the idle-timeout-seconds deployment descriptor) elapses. It doesn�t matter whether there is any pressure on the cache or not. With NRU on the other hand, the bean that exceeded the idle-timeout-seconds are removed from cache for good, when the cache gets filled up. Only inactive beans that didn�t exceed the idle-timeout-seconds are passivated.


If this is the case.
then the container will activate the 2 beans and give it to them(101, 102 ).And now the original client (that is 1, 2 clients ) agin they are invoking business method .Now they(1,2nd) should wait for any other 2 clients beans for passivation.

Well that�s the case though. The only one caveat is that when using NRU and the first two clients were inactive for longer than idle-timeout-seconds, then they have to create new instances, because the container removes the beans unmerciful. Luckily they are not using EJB handlers :-)
Regards.
 
Devender Thareja
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Valentin Tanase:

Well that�s the case though. The only one caveat is that when using NRU and the first two clients were inactive for longer than idle-timeout-seconds, then they have to create new instances, because the container removes the beans unmerciful. Luckily they are not using EJB handlers :-)
Regards.


Valentin,

I am little confused.
Are you saying with LRU, the bean will be reassigned to new client and original client will get a new bean. But isn't statefull beans supposed to maintain client state? So when the bean is reassined to new client, the state might be initialized to original default state. How the original cient will get a bean state where it left last?
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Devender,

Let's suppose that the cache is full and there is pressure for creating two new instances, from clients 101 & 102. Because beans 1 & 2 are not currently enlisted in a transaction, they are the good candidates for passivation (or removal with NRU if the idle-timeout-seconds were exceeded). After passivation and saving the bean�s state to the second storage, the container has two options: either completely removes the bean instances and creates two brand new ones, or reuses the current instances and re-initializes their state. Obviously for efficiency reasons the container will use the second approach. The container however will choose the first approach when NRU is selected and beans exceeded the idle-timeout-seconds.
When clients 1 & 2 are back, the container needs to get another two idle instances and associates them with the clients. There is no guarantee that these two instances are 101 & 102 (which replaced the previous 1 & 2). This time the container needs to restore the previous state and therefore will use the activation process in order to read the state from the second storage.
I hope this will clear things out for you.
Regards.
 
Devender Thareja
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Much clear now ! I forgot that bean can not be passivated while in transaction. I would assume that a bean's state can change only within a transaction. Hence state of bean can never lost due to passivation. Right?
Thanks.
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Devender,


Much clear now ! I forgot that bean can not be passivated while in transaction. I would assume that a bean's state can change only within a transaction. Hence state of bean can never lost due to passivation. Right?
Thanks.


Right. By the way you're very welcome
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!