Hi,
Ignore that last email please, my mailer's apparently messed up. (the
message is a few days old and is out of order).
Thanks,
WILL
----- Original Message -----
From: "Will Glass-Husain" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[EMAIL PROTECTED]>
Sent: Friday, January 30, 2004 7:44 AM
Subject: Re: [veltools] session tool init and synchronization
> Ok, at the risk of sounding stupiid, where do you call the synchronized
> method createSessionMutex? I guess the answer would be to check
> Session.isNew and call it then. (Just be sure to check isNew at the
> beginning of every request).
>
> WILL
>
> ----- Original Message -----
> From: "Claude Brisson" <[EMAIL PROTECTED]>
> To: "Velocity Developers List" <[EMAIL PROTECTED]>
> Sent: Friday, January 30, 2004 6:46 AM
> Subject: Re: [veltools] session tool init and synchronization
>
>
> > 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]
> >
>
>
> ---------------------------------------------------------------------
> 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]
