tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Radzom" <>
Subject RE: How to synchronize based on session? (Prevent multiple submissions of forms)
Date Wed, 02 Jul 2003 02:11:40 GMT

> -----Original Message-----
> From: Justin Ruthenbeck [] 
> Sent: Wednesday, July 02, 2003 2:20 AM
> To: Tomcat Users List
> Subject: RE: How to synchronize based on session? (Prevent 
> multiple submissions of forms)
> At 04:39 PM 7/1/2003, you wrote:
> >IMHO, Justin's proposal will not work since the servlet 
> container may choose
> >to pool multiple instances of the same servlet class and 
> assign an incoming
> >request to an available instance.
> Agreed. If the container chooses to pool multiple instances 
> of the same 
> servlet (I'm assuming this can be the case with Tomcat?), 
> then you're right 
> -- it won't work.

Sorry, I was a bit too fast here. The spec allows pooling of instances only
if the servlet implements SingleThreadModel. If the class does not implement
STM only one instance per jvm is allowed.

Given a non-distributed environment I would still prefer synchronizing on a
session attribute. Code like 

  Object lock = request.getAttribute("lock");
  synchronized (lock) { ; }

will have the desired effect.

> >Things get even worse in a distributed
> >environment involving multiple tomcats running in different jvms.
> >Because these requests are handled by multiple threads and maybe even
> >multiple servlet instances, the one thing in common to all 
> those requests is
> >the session object. IMO, a session attribute is the 
> preferable object to
> >sync.
> (The above was spliced together)
> If you're in a distributed environment, then synching on a session 
> attribute Object won't work either -- different JVMs have 
> different copies 
> of the same object.  The problem is that *any* 
> synchronization gets worse 
> when you're in a distributed environment.  If this is the case, then 
> nothing on the servlet level can *GUARANTEE* a lock -- enter 
> transactions.

> I don't see how this is possible without a third resource (such as a 
> database or other tx manager), but would like to know if you 
> can come up 
> with something.

You are right. In a distributed scenario additional means are needed:

* db or tx manager like you suggested
* use sticky sessions and implement like you would in a non-distributed


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message