Three times in a row, in this 4-mails long thread, I thought of an answer,
began to write it down, just to discover than Nathan or Will had just posted
exactly what I wanted to say.
You guys are fast !
Still, my opinion :
1. the mutex synchronizsation, as proposed by Will, is not only desirable
but mandatory : session tools are not so rare, especially for webapps that
provide authentification. Several instances of the same session-scoped tool
can then lead to very strange side effects (I encountered the problem with a
session-scoped upload tool that remembered the current directory under the
root of the loggued user).
2. to be rigorous, I would suggest the following synchronization method,
which I think is the only clean way :
public Object getSessionMutex()
{
Object ret = session.getAttribute(SESSION_MUTEX_ATTRIBUTE);
if (ret == null) ret = createSessionMutex( );
return ret;
}
public void synchronized createSessionMutex( )
{
// check again it doesn't already exist
if (session.getAttribute(SESSION_MUTEX_ATTRIBUTE) == null)
session.setAttribute(SESSION_MUTEX_ATTRIBUTE , new Object( ));
}
There is no performance drawback at all.
----- Original Message -----
From: "Will Glass-Husain" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[EMAIL PROTECTED]>
Sent: Friday, January 30, 2004 4:09 AM
Subject: Re: [veltools] session tool init and synchronization
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
