> -----Original Message-----
> From: Justin Ruthenbeck [mailto:[EMAIL PROTECTED]
> 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
environment
-Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
