• Post Reply Bookmark Topic Watch Topic
  • New Topic

Doubt in Http Session: Threading as in Servlet Spec 3.0  RSS feed

 
Anirudh Gupta
Ranch Hand
Posts: 49
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

Servlet 3.0 Specification. Section 7.7.1

Multiple servlets executing request threads may have active access to the same
session object at the same time.


Under what circumstances can such a scenario occur? Can someone elaborate on the above preferably with an example.
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All the time.

A servlet is not actually executing as a thread - at least in some J2EE servers. Rather, the server maintains a pool of service threads. When a request comes in, a service thread is taken from the pool and sent down the HTTP request/response cycle. One of the main stops along that route is the point where a servlet is located to handle the request and that servlet is invoked (via its process() method).

NO shared object is safe in a J2EE container. If you don't want unfortunate things to happen to objects in shared locations (such as instance properties in a servlet), then you MUST established synchronized access to them.
 
Anirudh Gupta
Ranch Hand
Posts: 49
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,

Thanks for taking the time to respond. I agree with your point and understand it.

However my doubt was more to do with ONLY the session object. An object which would anyway be created by the 1 thread that is serving the current request, if so required.

For this very session object to come into play again, a new request(being served by another thread-from pool or new Thread object, as you rightly pointed out) must contain
the JSESSIONID cookie associated for this very session object. It is my understanding that a client(browser or even a Java HTTP Client or any other) must set this header
to make a statefull call to an otherwise stateless protocol.

Now given the above scenario where and how can there be multiple threads wanting to access the same session object?

Mind you I agree with the fact that all objects in the J2ee environment must be stateless for threads.

Thanks.


 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The actual JSESSIONID value is simply a hash key into the server's map of HttpSession objects. It CAN come in via a cookie (The Java HTTPURLRequest class handles that automatically). OR it can come in as an appendage to the URL in the form ";jsessionid=......"

The session ID has no inherent meaning. In fact, if you switch from insecure to SSL transport, webapp servers will typically create a new session ID and re-file the session under that new ID so that the old session ID doesn't work any more. That's done to deny insecure requests access to the now-secured session data.

All it takes to get multiple concurrent requests on a session (and thereby on its session objects) is to submit multiple concurrent HTTP(S) requests. That is actually something that happens frequently without your knowing it, although user tics such as double-clicking a SUBMIT button also can cause it to happen and is the most common cause of trouble.

A typical web page is actually assembled as the product of multiple requests. In addition to the main page request, there may be images, javascript and css inclusions, even plugins each with its own URL. To speed up processing, these child requests, a client program will often multi-thread these requests, running them in parallel. I think 4-10 threads is about average, although some browsers allow manual tweaking. As a general rule, these secondary requests aren't going to care about session values. But there's no rule that says that they mustn't, so if they need to, they can. And will.
 
Anirudh Gupta
Ranch Hand
Posts: 49
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,

Nailed it! Very lucid. That is precisely what I was looking for, "a scenario".

Thanks so very much again.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!