aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes object pool for stateless session bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "object pool for stateless session bean" Watch "object pool for stateless session bean" New topic
Author

object pool for stateless session bean

Catherine Shan
Greenhorn

Joined: Sep 07, 2005
Posts: 5
Why EJB container needs to provide object pool for stateless session bean.?I know,mutiply thread can concurrently invoke method which is not synchronized.then why need POOL,if mutiply request only use ONE object, has it influence upon performance?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8898

Originally posted by Catherine Shan:
Why EJB container needs to provide object pool for stateless session bean.?I know,mutiply thread can concurrently invoke method which is not synchronized.then why need POOL,if mutiply request only use ONE object, has it influence upon performance?


Multiple threads cannot access the same SLSB instance.


Groovy
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Catherine,

Why EJB container needs to provide object pool for stateless session bean.?I know,mutiply thread can concurrently invoke method which is not synchronized.then why need POOL,if mutiply request only use ONE object, has it influence upon performance?

There are several reasons that demanded pooling SLSBs. At first is the multithreading issue. Generally speaking, in order to design a class thread safe one has two solutions: either uses the synchronized code (one instance many threads), either mandates that every concurrent thread access a different instance of that class (one instance per thread); as simple as that. Because enterprise beans are highly available components, synchronizing the code is not an option for ejbs. Hence the container must provide a way for each client thread to get a different bean instance. Here at least in theory, the container has two options: either create bean instances on demand using the new operator and/or the newInstance call, or to provide a pool of beans that could be shared by all threads. In theory the first approach has at least three "huge" drawbacks:
  • Creating the beans is a time consuming operation (especially because the container uses reflection).
  • It can raise memory issues, since the creation is not restricted or controlled in any ways.
  • There will be lots of unused instances that need to be garbage collected, which might reduce the application scalability.


  • Hence j2ee demanded the use of an instance pool, which again at least in theory will overcome all these issues.
    In practice though, things are quite different: modern garbage collector will easily handle the job. Bean instance creation is also not an issue since this operation is very fast and is mostly unmeasurable (taking probably about 0ms to execute), etc. But again this is another story...


    I think, therefore I exist -- Rene Descartes
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    It's interesting that the designers of Servlets took a different approach: a single instance (or very few) shared by many threads. What do you suppose drove them in different directions?


    A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
    Valentin Tanase
    Ranch Hand

    Joined: Feb 17, 2005
    Posts: 704
    Hi Stan,


    It's interesting that the designers of Servlets took a different approach: a single instance (or very few) shared by many threads. What do you suppose drove them in different directions?

    For once servlet are not thread safe and they should not be since they are not business components. They are just an improvement of the cgi interfaces and were designed with a very different goal in mind than ejbs (which provide implicit middleware services, like transaction, security, etc). Because they are multithreaded server components there is no reason to pool them. However some containers like weblogic for example, will always maintain a pool of servlet instances when they implement the SingleThreadModel interface.
    Regards.
    Catherine Shan
    Greenhorn

    Joined: Sep 07, 2005
    Posts: 5
    I see.Thank you for your reply,it's so helpful to me.


    Originally posted by Valentin Tanase:
    Hi Stan,


    For once servlet are not thread safe and they should not be since they are not business components. They are just an improvement of the cgi interfaces and were designed with a very different goal in mind than ejbs (which provide implicit middleware services, like transaction, security, etc). Because they are multithreaded server components there is no reason to pool them. However some containers like weblogic for example, will always maintain a pool of servlet instances when they implement the SingleThreadModel interface.
    Regards.
    Valentin Tanase
    Ranch Hand

    Joined: Feb 17, 2005
    Posts: 704
    You're very welcome Catherine
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: object pool for stateless session bean
     
    Similar Threads
    Question about Bean Pools
    Pooling stateless session beans vs singleton approach
    Basic Stateless session bean question
    HF questions and others - round 1
    Session Bean (Stateless bean) problem