You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2004/01/29 23:18:56 UTC
[veltools] session tool init and synchronization
hey folks, i'm looking for some feedback on this...
at issue is the synchronization of session tools initialization in
ServletToolboxManager.getToolboxContext(). the reason we have tried to
synchronize this block of code is to avoid multiple initializations of
session-scoped tools in situations where multiple simultaneous requests are
received from the same browser. (for background, see
http://marc.theaimsgroup.com/?l=velocity-dev&m=101837293614981&w=2 and the
subsequent responses in the thread).
the problem i'm now looking at is that it is apparently pointless to try
synchronizing on the session instance itself as the code currently does. (for
discussion of this, see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19223).
so, it seems to me that really only leaves us with two options:
-synchronize on the ServletToolboxManager instance. this will work, but is a
heavier-handed approach because it will allow session tools to be initialized
for only one session at a time, not just once per session.
-don't synchronize at all and leave it to the tool developer to be concerned
(or not) about whether the chance of initializing session tools multiple times
for the same session matters.
personally, i'm inclined to the second. in my personal experience, few
session tools are used and initialization of them is not generally costly, nor
would it be screwed up by happening multiple times for one user/session. on
top of that, the likelihood of mutliple-near simultaneous requests at session
initialization is quite low (especially for me since i don't use framesets in
my projects).
so, i guess my primary question is whether or not anyone else concerned about
this?
since the current synchronization is ineffective and i haven't heard news of
any problems, i'm guessing that the answer is "no," or at least "not so far."
as such, i'm going to go ahead and remove the synchronization for now. but i
wanted to put this out there to give people a heads up, see if this issue is a
real concern for anyone, and get any other thoughts on the matter.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Will Glass-Husain <wg...@forio.com>.
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" <wg...@forio.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
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" <cl...@savoirweb.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> 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" <wg...@forio.com>
> > To: "Velocity Developers List" <ve...@jakarta.apache.org>
> > 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" <na...@esha.com>
> > > To: "Velocity Developers List" <ve...@jakarta.apache.org>
> > > 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
> > > > nathan@esha.com
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
velocity-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Will Glass-Husain <wg...@forio.com>.
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" <cl...@savoirweb.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
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" <wg...@forio.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> 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" <na...@esha.com>
> > To: "Velocity Developers List" <ve...@jakarta.apache.org>
> > 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
> > > nathan@esha.com
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Claude Brisson <cl...@savoirweb.com>.
> 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" <ke...@aarhusmail.dk>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
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 <na...@esha.com> 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
> nathan@esha.com
>
>
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Kent Sølvsten Rasmussen <ke...@aarhusmail.dk>.
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 <na...@esha.com> 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
> nathan@esha.com
>
>
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Will Glass-Husain <wg...@forio.com>.
Nice. Elegant little bit of code. I'll have to update my version.
WILL
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Friday, January 30, 2004 7:51 AM
Subject: Re: [veltools] session tool init and synchronization
> 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
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Nathan Bubna <na...@esha.com>.
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
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Claude Brisson <cl...@savoirweb.com>.
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" <wg...@forio.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
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" <na...@esha.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> 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
> > nathan@esha.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Will Glass-Husain <wg...@forio.com>.
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" <na...@esha.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
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
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Nathan Bubna <na...@esha.com>.
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
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] session tool init and synchronization
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Nathan,
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.
The solution was to make my own simple session mutex, and then synchronize
on that object. Maybe this could be useful.
/**
* Get an object that can be synchronized across a session.
*/
public Object getSessionMutex()
{
Object ret = session.getAttribute(SESSION_MUTEX_ATTRIBUTE);
if (ret == null) {
ret = new Boolean(true);
session.setAttribute(SESSION_MUTEX_ATTRIBUTE,ret);
}
return ret;
}
You can then use this with:
Object mutex = getSessionMutex();
synchronized (mutex) {
some code
}
Best, WILL
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: <ve...@jakarta.apache.org>
Sent: Thursday, January 29, 2004 2:18 PM
Subject: [veltools] session tool init and synchronization
> hey folks, i'm looking for some feedback on this...
>
> at issue is the synchronization of session tools initialization in
> ServletToolboxManager.getToolboxContext(). the reason we have tried to
> synchronize this block of code is to avoid multiple initializations of
> session-scoped tools in situations where multiple simultaneous requests
are
> received from the same browser. (for background, see
> http://marc.theaimsgroup.com/?l=velocity-dev&m=101837293614981&w=2 and the
> subsequent responses in the thread).
>
> the problem i'm now looking at is that it is apparently pointless to try
> synchronizing on the session instance itself as the code currently does.
(for
> discussion of this, see
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19223).
>
> so, it seems to me that really only leaves us with two options:
>
> -synchronize on the ServletToolboxManager instance. this will work, but
is a
> heavier-handed approach because it will allow session tools to be
initialized
> for only one session at a time, not just once per session.
>
> -don't synchronize at all and leave it to the tool developer to be
concerned
> (or not) about whether the chance of initializing session tools multiple
times
> for the same session matters.
>
> personally, i'm inclined to the second. in my personal experience, few
> session tools are used and initialization of them is not generally costly,
nor
> would it be screwed up by happening multiple times for one user/session.
on
> top of that, the likelihood of mutliple-near simultaneous requests at
session
> initialization is quite low (especially for me since i don't use framesets
in
> my projects).
>
> so, i guess my primary question is whether or not anyone else concerned
about
> this?
>
> since the current synchronization is ineffective and i haven't heard news
of
> any problems, i'm guessing that the answer is "no," or at least "not so
far."
> as such, i'm going to go ahead and remove the synchronization for now.
but i
> wanted to put this out there to give people a heads up, see if this issue
is a
> real concern for anyone, and get any other thoughts on the matter.
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org