Hi all,

Almost all of the implementations of the Session per Request pattern that I have seen preassume that there's a 1-to-1 relationship between Http requests and Servlet container's threads, however nowhere in the Servlet spec is it specified that there should be such a relationship.

Although that most of the current Servlet containers handle request in this way, (i.e. establish a 1-to-1 relationship between requests and threads), there're implementations (experimental though) that can handle multiple requests in one thread. It seems that the current implementations of the Session per Request will broke down on such containers, but I'm not sure and I'm confused a little bit.

Does anybody have any ideas in this regard? I'll be thankful if you share your ideas in this regard with the rest of the members of the forum.

Regards,
Behi

Yes, and no :)

First, an association request -> Thread exists.

It is stated in the specifications that a a Request object should not be accessed from multiple threads. It is not threadsafe. It should only be accessed from the thread that created it. So use of request object in servlet, filters, and creation is supposed to occurs in same Thread.

Second. Is there an association Thread -> request.
Obviously, the specs don't state it. If one Thread would be uniquely associated to a request, then you couldn't do Thread pooling. You would be doomed to destriying thread after serving one request. Now the interresting part is to know if there is, at any given time during execution of a request, between the first filter call until the same filter exits (That is, the period when you do the request <-> Session association) a unique Thread -> Request association.
Let's look where, after entering the doFilter of the first filter, a Thread could pause it's work to start serving a new request.

Possibility 1: Between two filter, at the moment you call filterChain.doRequest(request,response)
However, spec states filterChain *must* locate the next filter and invoque it. So it does not have other options like pausing.

Possibility 2: Inside servlet/jsp
Call of some methods inside your servlet / jsp would have as side effect to check if there is some urgent request to serve and such request would be served prior to returning from method. Such a behavoir should be clearly documented as it is a side effect of the method. To my knowledge no such method exist, and if they were to exist, then simply never call them :)


Except for thread pooling (which is rather common) am curious to know how such implementation would be able to work without adding side effect to servlet specs methods, which are not documented to have such side effects.

Could you give example of such 'experimental' implementations.
Maybe Transaction systems might be interresting to look at, as it is common current transaction is associated with the current Thread.

So my idea is "Assume a 1 1 relationship during execution of request, between 1st filter call until same filter exit".