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]
