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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> > To: <users@tomcat.apache.org>
> > Sent: Friday, September 07, 2007 10:33 PM
> > Subject: Re: Concurrency with HttpSession
> >
> >
> >>
> >> "lightbulb432" <[EMAIL PROTECTED]> wrote
> in message
> >> news:[EMAIL PROTECTED]
> >>>
> >>> 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:
> [EMAIL PROTECTED]
> >>> For additional commands, e-mail:
> [EMAIL PROTECTED]
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
>
---------------------------------------------------------------------
> >> To start a new topic, e-mail:
> users@tomcat.apache.org
> >> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> >> For additional commands, e-mail:
> [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
>
---------------------------------------------------------------------
> > To start a new topic, e-mail:
> users@tomcat.apache.org
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
> >
>
> --
> 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:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
