EJB pooling vs servlet pooling

[Raf Szczypiorski]

Hi. When I was reading about the servlet technology, it said that SingleThreadModel is wrong, because it either serializes the threads / client, or creates a servlet pool. And this is deprecated, wrong. One of the point in Head First Servlets & JSP was that you can keep instance variables in a servlet to count incoming requsts, and when the clients are serialized, there is performance hit (aggreed), and when there is a pool, there is a possibility that different servlets will have different counts. I don't aggree with this opinion because you shouldn't reuse servlet instance vatiables for such tasks - the specs clearly says that the container can tear down a servlet instance whenever it wants to *(see below for exact quote), and when another request is made, it may create another, fresh instance, with the counter (or whatever the instance variable is) zeroed or nulled or initialized to its initial value. I even posted a query on this in sun forums and got the answer that I had expected - that context scope should be used for this, or some persistent storage **.

However, in stateless EJB, which are explicitly said not to preserve state and no instance variables should be used, that they use pooling, this (pooling) is good out of the blue? I mean, one of the features of an EJB container is "thread-safety" ***, which means that only one thread at a time can invoke a bean, because if another client want to use the same bean, another one from the pool is used. But what's the point if they are said not to preserve instance state?

I am probably wrong, because smarter than me invented this and wrote the specs. and I lack experience, but for now, I would regard servlets and stateless session beans very similar in principle (serving many clients and scalable and so on) using contradictory means to achieve this (for servlets pooling is bad and actually against the specs, statelss EJB use pooling and it is considered good and a feature).

Any comments form others smarter than me are welcome ;-)

* servlet-2_5-mrel2-spec.pdf, page 22
SRV.2.3.4 End of Service
The servlet container is not required to keep a servlet loaded for any particular period of time. A servlet instance may be kept active in a servlet container for a period of milliseconds, for the lifetime of the servlet container (which could be a number of days, months, or years), or any amount of time in between.

** http://forums.sun.com/thread.jspa?threadID=5329971&messageID=10416154#10416154

*** EJB 3 in Action, edition 3, table on page 22

[ December 12, 2008: Message edited by: Raf Szczypiorski ]
[ December 12, 2008: Message edited by: Raf Szczypiorski ]

[Tim Holloway]

Pooling is an inherent and expected attribute of EJBs. Servlets, on the other hand, were more ambiguous. Possible scenarios included:

1. Constructing and discarding servlets on a per-request basis.

2. Constructing single-instance servlets for the life of the server container.

3. Constructing multiple instances of a servlet for greater or lesser lifespans withing a container, possibly one per CPU. This seems to be the most common actual usage.

3. Operating multiple VMs each with some version of the above. For example, in a clustered environment.

I haven't read the latest specs, so I won't assert anything, but it's safest to assume the worst of all of the above, and thus neither instance members nor class members can be used with impunity.

In actual practice, I do occasionally have members in my servlets, because there are some very useful possibilities. I just code to expect the worst.

Some instance members might include loggers, per-instance statistical collectors (risky!) and the infrastructure required if the servlet is responsible for launching and managing long-term processes ("engines").

Some class members might include shared engine resources and class-level loggers.

The important thing is to remember that servlets are not as freely sharable as EJBs and that the degree of instance sharability/reusability can vary according to what you deploy them in, so if you're not careful, an app that appears to work just fine in one container may break in another.

[Raf Szczypiorski]

But why is "Pooling is an inherent and expected attribute of EJBs", as you say, and for servlets it is not? I just don't see a big difference here, honestly.

As for loggers or different engines as class / instance members in servlets - this is the same for EJBs - they too can have these engines, right?

[Jaikiran Pai]

Originally posted by Raf Szczypiorski:
However, in stateless EJB, which are explicitly said not to preserve state and no instance variables should be used, that they use pooling, this (pooling) is good out of the blue? I mean, one of the features of an EJB container is "thread-safety" ***, which means that only one thread at a time can invoke a bean, because if another client want to use the same bean, another one from the pool is used. But what's the point if they are said not to preserve instance state?

Raf,

If i understand you question right - You are asking why do we need pooling of Stateless session beans? Is that what you are asking? If yes, then have a look at this previous discussion about the same topic.

[Raf Szczypiorski]

Partly - what I don't understand is the thing that I kind of see SLSB as similar to servlets (maybe this is inherently wrong) - they could as well use single instance and new threads to serve clients, as no state should be preserved. And whereas SLSB can use pooling (even the specs say so), it is almost strictly prohibited for servlets, and I don't fully see why.
The topic you showed me just makes me feel better I am not the only person in doubt ;-)
Cheers.