> except that whole "not compiling" problem. ;)
yeah, weekend...
> To be even more rigorous, this seems like double-checked locking to me. It
will work almost always, but might fail under rare conditions.
well it only seems like :-)
there is no DCL here, because we don't use the Object on which we
synchronize, we just test its nullity (so partial initialization is
harmless).
----- Original Message -----
From: "Kent S�lvsten Rasmussen" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[EMAIL PROTECTED]>
Sent: Friday, January 30, 2004 6:16 PM
Subject: Re: [veltools] session tool init and synchronization
To be even more rigorous, this seems like double-checked locking to me. It
will work almost always, but might fail under rare conditions.
Nathan Bubna <[EMAIL PROTECTED]> wrote:
> Claude Brisson said:
> > 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).
>
> really? hmm. part of me wants to just dismiss this as a
> poorly designed
> webapp/tool, but a little synchronization once per user
> isn't too much to ask.
> ounce of prevention, pound of cure, yada yada yada. ;)
>
> > 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.
>
> except that whole "not compiling" problem. ;) i'm guessing
> that for the
> second method you meant:
>
> public Object synchronized createSessionMutex() {
> Object o =
> session.getAttribute(SESSION_MUTEX_ATTRIBUTE);
> if (o == null) {
> o = new Object();
> session.setAttribute(SESSION_MUTEX_ATTRIBUTE, o);
> }
> return o;
> }
>
> and yeah, i think that'll work! thanks for the tip!
>
> 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]
