• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

stateful beans

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
in a stateful bean ---the container doesn't create a pool. The bean is dedicated to the EJBObject for its entire life(probably why a pool is not created)
But when the bean is passivated the bean is destroyed, and when activated a new bean is created and assigned to the EJBObject.
So why isn't a pool created from which during activation a bean is assigned to the EJBObject instead of creating a new one.
 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


in a stateful bean ---the container doesn't create a pool. The bean is dedicated to the EJBObject for its entire life(probably why a pool is not created)
But when the bean is passivated the bean is destroyed, and when activated a new bean is created and assigned to the EJBObject.
So why isn't a pool created from which during activation a bean is assigned to the EJBObject instead of creating a new one.


Some vendors do choose to implement pooling in the scenario you describe. When people say stateful session beans are not pooled, they are referring to the logical concept (one stateful ejb for one client, do not get pooled).
 
k doshi
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes i agree, but i dont understand why in the logical concept also they have differentiated it that way
thks
kiran
 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Doshi,
Pooling is mainly done to improve the scalability by having a small number of instances servicing many clients.This is true with Stateless and entity beans. The reason that it is not possible with stateful session bean because the bean instance is saved relative to the ejbobject, but it is not like that in entity and stateless session beans. That is why they are put back in the pool and stateful session can't be pooled back or not reusable.
Rgds
Shankar
 
Ranch Hand
Posts: 341
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If that is the case then why would you passivate and then activate again? Once you passivate and serialize all the data, what happens to the bean instance?
I would think that by passivating, we reduce "in memory" data. Is this right?
 
Shankar Ranganathan
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Chintan,
I was talking about why we are not pooling stateful session bean.
The bean instance is saved in the filesystem but not disassociated from the ejbobject as in the case of entity and stateless and entity beans.In other word the ejbobject is always tied up with the bean instance in the case of stateful session bean.That is why we are not able reuse that bean instance for a different client which is possible with stateless and entity.Hope this makes sense.
Rgds
Shankar
 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason you cannot pool: the container never know about specific information stored in the bean. Imagine a bean like this:
class MyEJB ..... {
private int state = 0;
...
...
}
You can passivate this bean (to reduce RAM consumtion) and activate the bean (if client request it later), but there is no way you can reuse this bean for other client since the state of one client is different to the others. The container just doesn't have a way to modify the state.
Stateless bean won't have this problem since it should never store user-specific information in the bean itself, so it is safe for container to assume the bean is poolable.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic