Yep, I realized your point as I was typing my email. But it could only
potentially happen the before the mutex was initialized, e.g. the first time
the routine was called in the first request in the session. In my app,
those first requests are typically at a login screen, and there's not much
bad things that can happen there.
You could synchronize the method getSessionMutex. (which essentially
synchronizes to the servlet). This would be foolproof, but might have a
performance penalty. Alternately, you could implement a HttpSessionListener
(I've never done this) to initialize the mutex when the session is
initialized. But then you'd have to put this in the deployment descriptor.
(probably too complicated). Maybe someone else has a clever idea for
initializing the mutex.
The benefit of this getSessionMutex approach is that it's simple, and covers
almost all of the cases.
WILL
----- Original Message -----
From: "Nathan Bubna" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, January 29, 2004 4:12 PM
Subject: Re: [veltools] session tool init and synchronization
> Will Glass-Husain said:
> > I can't comment on whether or not the synchronization should occur (not
> > being a regular Tools user), but I hit this problem in a project and got
> > stung when I falsely assumed you could synchronize using the session
object.
> > This was a particular concern for me with web apps using frames, as the
> > multiple frames will simultaneously make HTTP requests. My experience
was a
> > classic intermittent failure problem where the system worked on my dev
> > server but not on the client's server-- a very frustrating debugging
> > experience.
>
> yeah, that's no fun.
>
> > The solution was to make my own simple session mutex, and then
synchronize
> > on that object. Maybe this could be useful.
>
> i thought about just doing something like this too, but i'm not sure it's
a
> totally secure method either. i'm by no means an expert in
> threading/synchronization issues, but what about a two-thread scenario
> where...
>
> > /** Get an object that can be synchronized across a session. */
> > public Object getSessionMutex()
> > {
>
> where thread #2 gets to the following line:
>
> > Object ret = session.getAttribute(SESSION_MUTEX_ATTRIBUTE);
> > if (ret == null) {
> > ret = new Boolean(true);
>
> while thread #1 is still in here and hasn't yet set the attribute
>
> > session.setAttribute(SESSION_MUTEX_ATTRIBUTE,ret);
> > }
> > return ret;
> > }
> >
> > You can then use this with:
> >
> > Object mutex = getSessionMutex();
> > synchronized (mutex) {
> > some code
> > }
>
> granted, your example would certainly be far more effective than
synchronizing
> on the session object, and in practice i'd imagine it would be *very*
unlikely
> to ever fail. but it seems to me that this could still theoretically
fail.
> or am i missing/misunderstanding something?
>
> Nathan Bubna
> [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
