Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Stateful Session Beans within Servlets  RSS feed

 
Jayr Motta
Ranch Hand
Posts: 110
Google App Engine Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A doubt that I always had is how is implemented the relation of servlets and EJBs, because I know that every requests in a common web server / app server will start a new thread that will call the method service() on an arbitrary servlet, but there will be just one instance of that servlet running by server, and I've also learned that stateful session beans creates a direct relation with a given class(the opposite of stateless that may assign any instance to respond to a given method call at any moment).

If a person access a servlet that, let's say is reponsible to manage a shopping cart, this person will send a request to a shared servlet (if it's a single node / server) and the only mechanism to identify that specific person is through the session created by the container, how can each person have its own instance of a given ejb responsible for its cart if the relationship of ejbs are done at class / reference level (because the servlet holds a reference to a proxy object that points to a single object of to a pool of objects)? There is some integration of EJB's with servlets to identify which EJB should be used for each http session? And even if it exists, how they deal with concurrent requests to the same EJB? (Because the EJB is an instance variable so it will leak state to other concurrent requests or synchronize them making it very slow).

 
ntumba lobo
Ranch Hand
Posts: 180
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For a servlet to work with a stateful session bean correctly, it needs to
1) do a manual JNDI look up to get a reference of the SFSB
2) store the ref to the SFSB in the HTTP session for future calls

that way each client will always use its own and same SFSB.

No instance variable in a servlet unless it is read only still applies.
 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Beside that, remember that there is no problem with concurrent access in SFSB.

Each client request is made to the same EJB instance, but multiple concurrent requests made from the same client (despite it's the real 'logical' client or not) will be transformed to multiple serial method invocations.
You can control this behaviour i.e. by using AccessTimeout annotation (http://download.oracle.com/javaee/6/api/javax/ejb/AccessTimeout.html)
 
Jayr Motta
Ranch Hand
Posts: 110
Google App Engine Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pedro,

This is fine, the issue I mentioned about concurrent requests was that I used to think that EJB's could be used with dependency injection and the application server would deal with the fact that the state of a servlet is shared among a lot of others requests, got it?

ntumba,

For each JNDI look up the app server will give me a brand new SFSB?


I took OCE EJB JEE6 recently and was approved, but I never had to use EJB's in this context, that's why I was curious!
 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Jayr

1. Yes, when you use the JNDI, the container is required to give you the fresh instance of the EJB.
2. Isn't the servlet variable, so a shared state between other requests, exactly the case of in which the invocations of a single user (although not 'logical' from your point of view but the user-servlet)?

Cheers
 
ntumba lobo
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually you do a JNDI lookup only once the first time then you store the SFSB in session.
The next time you need to call your SFSB you dont do a JNDI lookup but you get it from the HTTP session that way a client reuses the same SFSB instance.
I hope that'll help
 
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!