• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Maintain Session with Thread Safe

 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How To Maintain Session with Thread Safe? ie Using Sychronized to avoid that problem ... How to make this.. Please Discribe me..

Akshayan...
 
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since the Request object is thread safe and you get the Session object from the Request, any operations you do on a Session object within the scope of doGet() or doPost() will be thread safe.
 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, the request object is thread-safe. It is inherently in its nature. But the objects bound to the session can be potentially trouble spot. The only way( i think ) to screw a session is by opening multiple browser windows from the same client! In that situation, it is possible that multiple threads(from the same client) to access session state and to corrupt it. It is a non-likely scenario. But is can happen( most likely with IE, cause when you press ctrl+n, IE automatically creates request to the last visited page! Multiple ctrl+n will potentially create a problem).

Anyways, if you decide that's a risk you don't wanna take, couple of sollutions might come to mind :

1. Putting the service method synchronized(). Incredibly stupid sollution. That means that you'll permit one client to access your servlet at a time. It means only one thread, so your problem can be solved. But the price you'll pay is way to high.

2. Putting portions of the code, that uses the troubeling code, synchronized. That won't solve the problem, cause it will do nothing to prevent other threads to access the object. It will prevent the thread to lock the portion of the code, but it won't prevent other threads to use the troubeling object concurrently and inherently corrupt its state.

3. Whenever you use the troubeling object put a lock on the object itself. That would ensure that only one thread at a time is tamprering with session data.

Well, that how I see it. Everyone with hers/his oppinions is welcomed.

Ice
[ April 24, 2006: Message edited by: Ice Penov ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A single browser can run multiple HTTP request threads to do things like fetching two or more images at the same time. If you use frames or IFrames or whatever it can fetch two JSP pages concurrently. I think the HTTP spec somewhere suggests a two thread limit, but in IE you can set it higher and there's just no predicting what some unexpected browser might do.

So, yes, you can run into situations where you want to synchronize on the resource you're reading or modifying on the session. Synchronizing whole methods would scare me. Actually, synchronizing on anything is concerning; the system I work on was just destroyed by sync calls to rather long running JNDI lookups that just got longer and longer as they waited for each other.
 
When you have exhausted all possibilities, remember this: you haven't - Edison. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic