• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Doubt in Http Session: Threading as in Servlet Spec 3.0

 
Ranch Hand
Posts: 49
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic