You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by lightbulb432 <ve...@hotmail.com> on 2007/09/07 21:12:22 UTC
Concurrency with HttpSession
I'm reading some book concurrency books that talk about potential thread
safety issues with HttpSession. Specific cases follow:
- When the web container passivates an HttpSession while a user's request
modifies it
- When the web container replicates an HttpSession while a user's request
modifies it
- When multiple quick, successive requests from the same user access the
same HttpSession
Could somebody explain how Tomcat deals with the first two, and what steps
web application developers need to take to avoid concurrency problems with
all three cases above? Is it guaranteed that the passivated/replicated
object is always a consistent view of the HttpSession?
Thanks.
--
View this message in context: http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Wade Chandler <hw...@yahoo.com>.
--- Leon Rosenberg <ro...@googlemail.com>
wrote:
> On 9/7/07, lightbulb432 <ve...@hotmail.com>
> wrote:
> >
> > I'm reading some book concurrency books that talk
> about potential thread
> > safety issues with HttpSession. Specific cases
> follow:
> >
> > - When the web container passivates an HttpSession
> while a user's request
> > modifies it
>
> strange use case. why should that happen?
>
Yes, to me that would be a bug. I mean, if the server
were to be in the act of caching a dormant session out
to disk and out of memory when a request came in there
should be a lock in place, and then once it finished
doing so, the lock would be released, the session
would be brought back into memory, and all should be
well. If not, then it simply would not work and would
be bad coding...that is when you file a bug.
> > - When the web container replicates an HttpSession
> while a user's request
> > modifies it
>
> Hmm.. Is it a real issue for you?
>
Again, if it were doing so, same as the above issue.
If the server or infrastructure for clustering were
doing anything related to copying out to keep multiple
instances up to date I would expect concurrency to be
controlled at the server and cluster level, and if not
then it would simply be a bug. I don't see how it
could be anything else unless the clustering support
allowed you, in configurable instances, to tell it not
to be so rigid and allow access to these things even
when they may not yet be up to date. Then in this case
you would have to know your logic well enough to know
if it would be an issue or not, and would hope being
rigid would be the default.
> > - When multiple quick, successive requests from
> the same user access the
> > same HttpSession
>
> No problem here, at least not with 2.5 compliant
> server.
>
My other reply was specifically about this.
Wade
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Leon Rosenberg <ro...@googlemail.com>.
On 9/7/07, lightbulb432 <ve...@hotmail.com> wrote:
>
> I'm reading some book concurrency books that talk about potential thread
> safety issues with HttpSession. Specific cases follow:
>
> - When the web container passivates an HttpSession while a user's request
> modifies it
strange use case. why should that happen?
> - When the web container replicates an HttpSession while a user's request
> modifies it
Hmm.. Is it a real issue for you?
> - When multiple quick, successive requests from the same user access the
> same HttpSession
No problem here, at least not with 2.5 compliant server.
regards
Leon
>
> Could somebody explain how Tomcat deals with the first two, and what steps
> web application developers need to take to avoid concurrency problems with
> all three cases above? Is it guaranteed that the passivated/replicated
> object is always a consistent view of the HttpSession?
>
> Thanks.
> --
> View this message in context: http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Wade Chandler <hw...@yahoo.com>.
I had been too quick with it before, and came up with
what I think is a better fix. I haven't submitted a
patch, but I suppose I could. I work on the NetBeans
project and it would be about the same. For anyone
interested in this issue it is at:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43343
Wade
--- Christopher Schultz <ch...@christopherschultz.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wade,
>
> Wade Chandler wrote:
> > Do you want to file a bug or do you want me to?
> I'm
> > looking at the Tomcat 6.0.9 source code.
>
> Even if nobody decides to do anything, please PLEASE
> log this bug and
> get this discussion into bugzilla.
>
> Thanks,
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla -
> http://enigmail.mozdev.org
>
>
iD8DBQFG5WNd9CaO5/Lv0PARAuEOAKCdmSe8o0U6HNVhux9GTDKCXDOZmQCgutEk
> K2bbhI7o08vs6iYOChp1U34=
> =Cugw
> -----END PGP SIGNATURE-----
>
>
---------------------------------------------------------------------
> To start a new topic, e-mail:
> users@tomcat.apache.org
> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:
> users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wade,
Wade Chandler wrote:
> Do you want to file a bug or do you want me to? I'm
> looking at the Tomcat 6.0.9 source code.
Even if nobody decides to do anything, please PLEASE log this bug and
get this discussion into bugzilla.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG5WNd9CaO5/Lv0PARAuEOAKCdmSe8o0U6HNVhux9GTDKCXDOZmQCgutEk
K2bbhI7o08vs6iYOChp1U34=
=Cugw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Wade Chandler <hw...@yahoo.com>.
You got my attention, so I was curious.
Looking at file:
java/org/apache/catalina/session/PersistentManagerBase.java
methods:
swapIn
swapOut
writeSession
findSession
(other related)
then the different stores load and save methods it
doesn't look good.
Basically, yes, you have an issue with Tomcat and
session passivation, unless I missed something else.
It does not have code for locking the session during
read and write.
What really needs to happen is a session needs to have
an instance variable which can be used for a
synchronization lock at the session level. In
ManagerBase.findSession, this lock would be used
before the session map is accessed. After the session
map is accessed it should then return null if the
session had been passivating before it was asked to be
found. It would then be loaded before it was ever
given back to be accessed. It would also be used in
PersistentManagerBase.swapOut like this:
protected void swapOut(Session session) throws
IOException {
if (store == null || !session.isValid()) {
return;
}
synchronized(session.locker){
//some check(s) needs to be added to see
//if the session was accessed before
//the call to initiate this process
//occurred
((StandardSession)session).passivate();
writeSession(session);
super.remove(session);
session.recycle();
}
}
This way a session can not be found before it is
completely written to disk/store. Some checks, as
mentioned in a comment in the code, need to be in
place to make sure the session was not accessed after
the method was called. It could be that the method is
called to begin right as the session has been accessed
and after the lock is released in findSession. So, you
would have a session and have some issues. Your user
would have a time when they thought they set something
or your code could think this then immediately the
changes are lost. Anyways, that is what looks to be
the issue.
The only way you could possibly *sort of* workaround
this issue would be to use a
HttpSessionActivationListener, but even then it would
be hard to code up a 100% reliable solution. You can
see how this would *sort of* be a way to work around
the issue by looking at the Tomcat class
StandardSession method passivate (in the same folder
as PersistentManagerBase.java), and see the events
will be thrown, but it would be pretty complicated and
ugly. This reminds me of the Session and Application
HashMap issue I mentioned before. It may not be the
case, but in that instance the developer thought
skipping the locks would speed up the server, but the
issue made it (Tomcat) less reliable and the speed
gain was by no means a match for the possible data
loss.
Do you want to file a bug or do you want me to? I'm
looking at the Tomcat 6.0.9 source code.
Wade
--- lightbulb432 <ve...@hotmail.com> wrote:
>
> I'm not talking about EJBs, but rather about any
> Tomcat-specific passivation
> that is done for HttpSessions that haven't been
> accessed in a while (just a
> memory use optimization).
>
> Regarding my question in general, I'm wondering
> (maybe this is more of a
> serialization question in general), if the container
> decides to serialize to
> disk a session with 10 attributes, and the following
> happens, wouldn't it
> result in an inconsistent serialized session? The
> container's thread
> finishes writing the first 5 attributes to disk,
> then a request's thread
> updates two session attributes (one from the first
> 5, one from the next 5),
> then the container writes the next 5 attributes to
> disk.
>
> You'd have an inconsistent serialized view, right?
> With only one of the two
> attribute updates reflected in the session. Sure,
> you'd assume that once a
> request accesses the session, the passivation would
> stop. Nonetheless, what
> thread-safety issues might arise with Tomcat in this
> case and others?
>
> I'm asking more for learning than any particular
> issue I'm having.
>
>
>
> mgainty wrote:
> >
> > I found this doc applicable
> > "You can pass the HttpSession as parameter to an
> EJB method, only if all
> > objects in session are serializable.
> > This has to be consider as passed-by-value, that
> means that it's read-only
> > in the EJB.
> > If anything is altered from inside the EJB, it
> won't be reflected back to
> > the HttpSession of the Servlet Container"
> >
> > More to the point of your test scenario:
> > The pass-by-reference can be used between EJBs
> Remote Interfaces, as they
> > are remote references.
> > While it is possible to pass an HttpSession as a
> parameter to an EJB
> > object,
> > it is considered to be bad practice in terms of
> object-oriented design.
> > This is because you are creating an unnecessary
> coupling between back-end
> > objects (EJBs) and front-end objects
> (HttpSession).
> >
> > In any case could you post an the aforementioned
> where the session
> > attributes are being modified so we can look at
> it..
> >
> > Thanks/
> > M--
> > This email message and any files transmitted with
> it contain confidential
> > information intended only for the person(s) to
> whom this email message is
> > addressed. If you have received this email
> message in error, please
> > notify
> > the sender immediately by telephone or email and
> destroy the original
> > message without making a copy. Thank you.
> >
> > ----- Original Message -----
> > From: "Bill Barker" <wb...@wilshire.com>
> > To: <us...@tomcat.apache.org>
> > Sent: Friday, September 07, 2007 10:33 PM
> > Subject: Re: Concurrency with HttpSession
> >
> >
> >>
> >> "lightbulb432" <ve...@hotmail.com> wrote
> in message
> >> news:12561600.post@talk.nabble.com...
> >>>
> >>> I'm reading some book concurrency books that
> talk about potential thread
> >>> safety issues with HttpSession. Specific cases
> follow:
> >>>
> >>> - When the web container passivates an
> HttpSession while a user's
> >>> request
> >>> modifies it
> >>
> >> Should be rare, but I don't see anything in the
> TC code to prevent it
> >> from
> >> happening on edge cases. If someone can
> construct an example, I'd be
> >> more
> >> than happy to look into it.
> >>
> >>> - When the web container replicates an
> HttpSession while a user's
> >>> request
> >>> modifies it
> >>
> >> I believe that with pessimistic locking, this
> shouldn't happen. But I'm
> >> not an expert on the TC replication code :).
> >>
> >>
> >>> - When multiple quick, successive requests from
> the same user access the
> >>> same HttpSession
> >>>
> >>> Could somebody explain how Tomcat deals with the
> first two, and what
> >>> steps
> >>> web application developers need to take to avoid
> concurrency problems
> >>> with
> >>> all three cases above? Is it guaranteed that the
> passivated/replicated
> >>> object is always a consistent view of the
> HttpSession?
> >>>
> >>> Thanks.
> >>> --
> >>> View this message in context:
> >>>
>
http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600
> >>> Sent from the Tomcat - User mailing list archive
> at Nabble.com.
> >>>
> >>>
> >>>
>
---------------------------------------------------------------------
> >>> To start a new topic, e-mail:
> users@tomcat.apache.org
> >>> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail:
> users-help@tomcat.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
>
---------------------------------------------------------------------
> >> To start a new topic, e-mail:
> users@tomcat.apache.org
> >> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail:
> users-help@tomcat.apache.org
> >>
> >>
> >
> >
> >
>
---------------------------------------------------------------------
> > To start a new topic, e-mail:
> users@tomcat.apache.org
> > To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail:
> users-help@tomcat.apache.org
> >
> >
> >
>
> --
> View this message in context:
>
http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12575563
> Sent from the Tomcat - User mailing list archive at
> Nabble.com.
>
>
>
---------------------------------------------------------------------
> To start a new topic, e-mail:
> users@tomcat.apache.org
> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:
> users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by lightbulb432 <ve...@hotmail.com>.
I'm not talking about EJBs, but rather about any Tomcat-specific passivation
that is done for HttpSessions that haven't been accessed in a while (just a
memory use optimization).
Regarding my question in general, I'm wondering (maybe this is more of a
serialization question in general), if the container decides to serialize to
disk a session with 10 attributes, and the following happens, wouldn't it
result in an inconsistent serialized session? The container's thread
finishes writing the first 5 attributes to disk, then a request's thread
updates two session attributes (one from the first 5, one from the next 5),
then the container writes the next 5 attributes to disk.
You'd have an inconsistent serialized view, right? With only one of the two
attribute updates reflected in the session. Sure, you'd assume that once a
request accesses the session, the passivation would stop. Nonetheless, what
thread-safety issues might arise with Tomcat in this case and others?
I'm asking more for learning than any particular issue I'm having.
mgainty wrote:
>
> I found this doc applicable
> "You can pass the HttpSession as parameter to an EJB method, only if all
> objects in session are serializable.
> This has to be consider as passed-by-value, that means that it's read-only
> in the EJB.
> If anything is altered from inside the EJB, it won't be reflected back to
> the HttpSession of the Servlet Container"
>
> More to the point of your test scenario:
> The pass-by-reference can be used between EJBs Remote Interfaces, as they
> are remote references.
> While it is possible to pass an HttpSession as a parameter to an EJB
> object,
> it is considered to be bad practice in terms of object-oriented design.
> This is because you are creating an unnecessary coupling between back-end
> objects (EJBs) and front-end objects (HttpSession).
>
> In any case could you post an the aforementioned where the session
> attributes are being modified so we can look at it..
>
> Thanks/
> M--
> This email message and any files transmitted with it contain confidential
> information intended only for the person(s) to whom this email message is
> addressed. If you have received this email message in error, please
> notify
> the sender immediately by telephone or email and destroy the original
> message without making a copy. Thank you.
>
> ----- Original Message -----
> From: "Bill Barker" <wb...@wilshire.com>
> To: <us...@tomcat.apache.org>
> Sent: Friday, September 07, 2007 10:33 PM
> Subject: Re: Concurrency with HttpSession
>
>
>>
>> "lightbulb432" <ve...@hotmail.com> wrote in message
>> news:12561600.post@talk.nabble.com...
>>>
>>> I'm reading some book concurrency books that talk about potential thread
>>> safety issues with HttpSession. Specific cases follow:
>>>
>>> - When the web container passivates an HttpSession while a user's
>>> request
>>> modifies it
>>
>> Should be rare, but I don't see anything in the TC code to prevent it
>> from
>> happening on edge cases. If someone can construct an example, I'd be
>> more
>> than happy to look into it.
>>
>>> - When the web container replicates an HttpSession while a user's
>>> request
>>> modifies it
>>
>> I believe that with pessimistic locking, this shouldn't happen. But I'm
>> not an expert on the TC replication code :).
>>
>>
>>> - When multiple quick, successive requests from the same user access the
>>> same HttpSession
>>>
>>> Could somebody explain how Tomcat deals with the first two, and what
>>> steps
>>> web application developers need to take to avoid concurrency problems
>>> with
>>> all three cases above? Is it guaranteed that the passivated/replicated
>>> object is always a consistent view of the HttpSession?
>>>
>>> Thanks.
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600
>>> Sent from the Tomcat - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12575563
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Martin Gainty <mg...@hotmail.com>.
I found this doc applicable
"You can pass the HttpSession as parameter to an EJB method, only if all
objects in session are serializable.
This has to be consider as passed-by-value, that means that it's read-only
in the EJB.
If anything is altered from inside the EJB, it won't be reflected back to
the HttpSession of the Servlet Container"
More to the point of your test scenario:
The pass-by-reference can be used between EJBs Remote Interfaces, as they
are remote references.
While it is possible to pass an HttpSession as a parameter to an EJB object,
it is considered to be bad practice in terms of object-oriented design.
This is because you are creating an unnecessary coupling between back-end
objects (EJBs) and front-end objects (HttpSession).
In any case could you post an the aforementioned where the session
attributes are being modified so we can look at it..
Thanks/
M--
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
----- Original Message -----
From: "Bill Barker" <wb...@wilshire.com>
To: <us...@tomcat.apache.org>
Sent: Friday, September 07, 2007 10:33 PM
Subject: Re: Concurrency with HttpSession
>
> "lightbulb432" <ve...@hotmail.com> wrote in message
> news:12561600.post@talk.nabble.com...
>>
>> I'm reading some book concurrency books that talk about potential thread
>> safety issues with HttpSession. Specific cases follow:
>>
>> - When the web container passivates an HttpSession while a user's request
>> modifies it
>
> Should be rare, but I don't see anything in the TC code to prevent it from
> happening on edge cases. If someone can construct an example, I'd be more
> than happy to look into it.
>
>> - When the web container replicates an HttpSession while a user's request
>> modifies it
>
> I believe that with pessimistic locking, this shouldn't happen. But I'm
> not an expert on the TC replication code :).
>
>
>> - When multiple quick, successive requests from the same user access the
>> same HttpSession
>>
>> Could somebody explain how Tomcat deals with the first two, and what
>> steps
>> web application developers need to take to avoid concurrency problems
>> with
>> all three cases above? Is it guaranteed that the passivated/replicated
>> object is always a consistent view of the HttpSession?
>>
>> Thanks.
>> --
>> View this message in context:
>> http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600
>> Sent from the Tomcat - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Bill Barker <wb...@wilshire.com>.
"lightbulb432" <ve...@hotmail.com> wrote in message
news:12561600.post@talk.nabble.com...
>
> I'm reading some book concurrency books that talk about potential thread
> safety issues with HttpSession. Specific cases follow:
>
> - When the web container passivates an HttpSession while a user's request
> modifies it
Should be rare, but I don't see anything in the TC code to prevent it from
happening on edge cases. If someone can construct an example, I'd be more
than happy to look into it.
> - When the web container replicates an HttpSession while a user's request
> modifies it
I believe that with pessimistic locking, this shouldn't happen. But I'm not
an expert on the TC replication code :).
> - When multiple quick, successive requests from the same user access the
> same HttpSession
>
> Could somebody explain how Tomcat deals with the first two, and what steps
> web application developers need to take to avoid concurrency problems with
> all three cases above? Is it guaranteed that the passivated/replicated
> object is always a consistent view of the HttpSession?
>
> Thanks.
> --
> View this message in context:
> http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Wade Chandler <hw...@yahoo.com>.
I suppose in a situation where a server did not handle
concurrency for you in the lowest possible level the
version of JSTL and EL and such things which it used
could handle concurrency by wrapping such access, but
this would then mean you could not access the session
in regular coding practices because you would not have
access to the same locks the JSP support code was
using, so you as a developer would have to choose
between some pure JSP versus servlet type application
instead of mixing the two, and even then I don't see
how you could truly use JSP as you have to access your
logic and the session one way or another at some
point...that or make your own session, so I don't
think with the current specifications it would be
possible for a server to be reliable for any real
usage if it did not handle the concurrency issues
itself at the lowest possible levels.
Wade
--- Wade Chandler <hw...@yahoo.com>
wrote:
> Tomcat wraps HttpSession objects underlying maps
> using
> java.util.Collections.synchronizedMap. There was a
> previous issue in a version of Tomcat 5.0.x
> something
> in which this was changed, and it raised a stink, so
> it was fixed again. It had to be put back to use
> synchronized as the concurrency issues caused such
> headaches the developer had no way to manage this
> from
> an application perspective. I can't imagine Tomcat
> would have calls which are not synchronized to pull
> a
> session back from storage either. The user certainly
> would not have any control over such a thing as JSP
> session access can not be wrapped easily by
> developers
> using normal synchronization techniques. Are you
> having some specific issue?
>
> Wade
>
> --- lightbulb432 <ve...@hotmail.com> wrote:
>
> >
> > I'm reading some book concurrency books that talk
> > about potential thread
> > safety issues with HttpSession. Specific cases
> > follow:
> >
> > - When the web container passivates an HttpSession
> > while a user's request
> > modifies it
> > - When the web container replicates an HttpSession
> > while a user's request
> > modifies it
> > - When multiple quick, successive requests from
> the
> > same user access the
> > same HttpSession
> >
> > Could somebody explain how Tomcat deals with the
> > first two, and what steps
> > web application developers need to take to avoid
> > concurrency problems with
> > all three cases above? Is it guaranteed that the
> > passivated/replicated
> > object is always a consistent view of the
> > HttpSession?
> >
> > Thanks.
> > --
> > View this message in context:
> >
>
http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600
> > Sent from the Tomcat - User mailing list archive
> at
> > Nabble.com.
> >
> >
> >
>
---------------------------------------------------------------------
> > To start a new topic, e-mail:
> > users@tomcat.apache.org
> > To unsubscribe, e-mail:
> > users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail:
> > users-help@tomcat.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To start a new topic, e-mail:
> users@tomcat.apache.org
> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:
> users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Concurrency with HttpSession
Posted by Wade Chandler <hw...@yahoo.com>.
Tomcat wraps HttpSession objects underlying maps using
java.util.Collections.synchronizedMap. There was a
previous issue in a version of Tomcat 5.0.x something
in which this was changed, and it raised a stink, so
it was fixed again. It had to be put back to use
synchronized as the concurrency issues caused such
headaches the developer had no way to manage this from
an application perspective. I can't imagine Tomcat
would have calls which are not synchronized to pull a
session back from storage either. The user certainly
would not have any control over such a thing as JSP
session access can not be wrapped easily by developers
using normal synchronization techniques. Are you
having some specific issue?
Wade
--- lightbulb432 <ve...@hotmail.com> wrote:
>
> I'm reading some book concurrency books that talk
> about potential thread
> safety issues with HttpSession. Specific cases
> follow:
>
> - When the web container passivates an HttpSession
> while a user's request
> modifies it
> - When the web container replicates an HttpSession
> while a user's request
> modifies it
> - When multiple quick, successive requests from the
> same user access the
> same HttpSession
>
> Could somebody explain how Tomcat deals with the
> first two, and what steps
> web application developers need to take to avoid
> concurrency problems with
> all three cases above? Is it guaranteed that the
> passivated/replicated
> object is always a consistent view of the
> HttpSession?
>
> Thanks.
> --
> View this message in context:
>
http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600
> Sent from the Tomcat - User mailing list archive at
> Nabble.com.
>
>
>
---------------------------------------------------------------------
> To start a new topic, e-mail:
> users@tomcat.apache.org
> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:
> users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org