• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Session Beans

 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
I have two questions concerning EJBs:
- For a Stateful session bean, is there a concept of instance pooling by the server?
- Does Stateless OR Stateful session beans supports concurrent requests?
:roll:
yup
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Raj Waters:
Hi
I have two questions concerning EJBs:
- For a Stateful session bean, is there a concept of instance pooling by the server?
- Does Stateless OR Stateful session beans supports concurrent requests?
:roll:
yup


My answers may not be correct but to my knowledge,
1) Some (or most) app servers pool stateful session beans by seperating the state information from the bean reference, during passivation.
2) Each client is alloted one session bean to process its request and during that time no other client can access this session bean, but the same client can be allowed to reenter the ejb depending on your setting in the deployment descriptor for reentrant property.
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Vinod Jon:
2) Each client is alloted one session bean to process its request and during that time no other client can access this session bean, but the same client can be allowed to reenter the ejb depending on your setting in the deployment descriptor for reentrant property.


Actually, the reentrant attribute only applies to entity beans.
About Session Bean concurrency...

Section 7.5.6 of the EJB 2.0 Specification:
A container serializes calls to each session bean instance. Most containers will support many instances of a session bean executing concurrently; however, each instance sees only a serialized sequence of method calls. Therefore, a session bean does not have to be coded as reentrant.
The container must serialize all the container-invoked callbacks (that is, the methods ejbPassivate, beforeCompletion, and so on), and it must serialize these callbacks with the client-invoked business method calls.
Clients are not allowed to make concurrent calls to a stateful session object. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client[4], if the client is a remote client, or the javax.ejb.EJBException, if the client is a local client. This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean class.

 
Ranch Hand
Posts: 8943
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dont think that it is right. Stateful session bean cannot be pooled becauase the Class.newInstance method on the bean class must be called when the client calls the create method.
Please have a look at the life cycle of SFSB.
when client class create() the following steps are executed
1. newInstance()
2. setSessionContext(sc)
3. ejbCreate<METHOD>(args)
Also from the spec -
The container�s caching algorithm may decide that the bean instance should be evicted from
memory (this could be done at the end of each method, or by using an LRU policy).
------
It is clear that the bean will be removed from the memory => no pooling.

Originally posted by Vinod Jon:

My answers may not be correct but to my knowledge,
1) Some (or most) app servers pool stateful session beans by seperating the state information from the bean reference, during passivation.

 
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Pradeep Bhat:
the Class.newInstance method on the bean class must be called when the client calls the create method.


This doesn't mean that all the stateful session beans should be created from scratch. When you can seperate the bean state from the bean instance, why can't we reuse the bean instance ?.
App server also simulate pool by swapping already created instance.
Chris:
Thanks for correcting me.
 
Pradeep bhatt
Ranch Hand
Posts: 8943
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vinod,
I would apprericiate if you could send me some links regarding this.
Also, please post the app server name that support SFSB pooling
Thanks in adv.
pradeep
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pradeeb, JGuru.com has a FAQ entry about SFSB instance pooling.
 
Pradeep bhatt
Ranch Hand
Posts: 8943
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the link!
Can you also tell me which server does actually implement SFSB?
 
She said she got a brazillian. I think owning people is wrong. That is how I learned ... tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic