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]
