• Post Reply Bookmark Topic Watch Topic
  • New Topic

How does an EJB treat multiple requests when compared to a Servlet?  RSS feed

 
Mathew Chen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
How does an Entity Bean treat multiple requests when compared to a Servlet?Does pooling in this case?

Thanks
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mathew,

The big difference is that servlets are not thread safe; hence there is no need to pool them. However some containers might maintain a pool of servlet instances in some circumstances. Weblogic for example maintains such a pool for each servlet implementing the SingleThreadedModel interface. SLSB on the other hand are always pooled because they are designed to be thread safe component and different client threads access a different bean instance.
Regards.
 
Mathew Chen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Valentine for your reply.I am not very clear about the relationship between the need for pooling and threading.Could you please elaborate?

Thanks again

Mathew
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let�s try to implement two very simple components that change an instance variable. First let�s look at the servlet:

public class IncrementServlet extends HttpServlet {
private int increment;

public doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
1: increment = 0;
2: // Do Some logic here for this client.
3: increment++;
System.out.println(�increment: � + increment);
}
}
One would expect the servlet to print this line �increment: 1�. Well that�s not always true and the reason is very simple: the next sequence of execution is possible to happen:
  • Client 1: executes line 1 and starts the execution block in line 2.
  • Client 2: executes line 1, 2, 3 and finishes before client 1 exiting the block of code starting at line 2.
  • Client 1: executes the line 3.

  • Finally the servlet will print the line �increment: 2�; as you can see the result is highly unpredictable.
    Let�s see the same example with an SLSB:

    public class IncrementBean implements SessionBean {
    private int increment;

    public void increment() {
    1: increment = 0;
    2: // Do Some logic here for this client.
    3: increment++;
    System.out.println(�increment: � + increment);
    }
    }
    This time our intuition is always true: the application will always print 1.
    The difference is that in the first case the clients accessed the same servlet instance and therefore they could change the same increment attribute. On the second case the clients always talk to different bean instances and they increment different increment attributes. If the servlet would implement the SingleThreadedModel interface then it would have the same result as the bean has. However this is a very bad and un-recommended practice. The other better and obvious solution would be to declare the increment as a local variable and not instance variable. Hence changing the Line 1 in servlet like this:

    Will always work.
    Please let me know if you have anymore questions.
    Regards.
     
    Mathew Chen
    Greenhorn
    Posts: 18
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Valentine for your detailed response.I really appreciate it.

    Regards
    Mathew
     
    Valentin Tanase
    Ranch Hand
    Posts: 704
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You�re very welcome Mathew, I�m glad I could help
     
    sarah Marsh
    Ranch Hand
    Posts: 282
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Hence changing the Line 1 in servlet like this:

    code:
    -----------------------------------------------------------------

    1: int increment = 0;

    -----------------------------------------------------------------


    Hello: is this safe? Or better use Synchronize block?
     
    Valentin Tanase
    Ranch Hand
    Posts: 704
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Sarah,

    Yes it is because the increment variable was defined inside of the method (kind of auto variable; the compiler will push it on the method�s stack, etc). I should probably make clear that the increment instance variable, defined at the top of the class definition should go away (otherwise the code won�t even compile).
    Regards.
     
    Thomas Becker
    Greenhorn
    Posts: 23
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Valentin, you described why no one should ever use instance variables in servlets, without a very good reason to do so.
     
    Roger Chung-Wee
    Ranch Hand
    Posts: 1683
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    There is an excellent reason for doing so: thread safety. Typically, servlets are multithreaded because the container will obtain good use of resources this way rather than instantiate a servlet per request. Non-local variables (which are not final) are then are risk of being changed by concurrent threads, thus producing wrong results for some threads.

    But local variables are not at risk as they only run in the thread in which they are created. As local variables are invariably thread safe, you would need a pretty good reason to use non-final instance or class variables in servlets.
     
    Thomas Becker
    Greenhorn
    Posts: 23
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    @Roger: Thats exactly what I wanted to say. Thank you.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!