https://bz.apache.org/bugzilla/show_bug.cgi?id=66513
Christopher Schultz <ch...@christopherschultz.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Vincent Liautaud from comment #2)
> I confirm that this issue happens when using only one node.
Interesting.
> In my opinion, the issue comes from the session object used to synchronize
> the delete/insert sql request in DataSourceStore/JDBCStore. From what i can
> see the session object is different for each request (the session attributes
> can be the same but the objects themselves are different).
Aha, yes. I believe the PersistentValve causes the session to be re-loaded for
each request. So that could result in separate Session objects in memory for a
single session-id.
I think this would be very difficult to "fix" because the application will get
whatever session is returned by the Manager at the time it is requested. Thread
A may cause the session to be loaded from storage and handed to Request A only
to have Thread B do the same thing immediately afterward.
You are right: they will get separate objects each time, and therefore
synchronization is nearly impossible. I'm not sure what the best was to do this
is, because it's very easy to make bad mistakes like synchronizing on the whole
session-store which will kill performance.
> I made a test by replacing the "synchtonize(session)" by a
> "synchronize(lock)" with a lock object define like this : "private static
> final Object lock = new Object();"
> => It solves the issue (all "primary key constraint violation" disappear.
> Of course this is not the good solution because it synchronize the code
> block for each request, even for request using different sessionId (what
> could cause performance problems).
>
> That is why i suggested to lock on a object that would lock all requests
> using the same sessionId.
This could be done with a separate map of locks-for-session-ids. Or maybe lock
on the String object which holds the session-id as the key of the
session-id-to-Session map. Though I don't think you can ask a Map for its key
object(s) without iterating through the whole set of Map.Entry values.
String.intern?
> Finaly regarding the race condition you mention at the end of your comment,
> this is not something that should happen in our standard JEE application
> using sessionIds stored in cookies (as all the servlet requests using a
> specific sessionId should come from a unique client/browser "in sequence" -
> no AJAX usage or equivalent => So we should not attend conditions where
> concurrent requests updating the session attributes for a same sessionId be
> treated by different nodes in //. The issue we face with those "primary key
> violation" comes from an incomplete filter (where some requests on static
> components like gif/css/... are not filtered correctly).
>
> Do you agree with that ?
Yes, I think so. Thanks for giving more details about your specific use-case.
Specifically, you aren't trying to ensure bullet-proof session-management under
high-frequency session-contention. This is mostly about the
PersistentValve+PersistentManager+DataSourceStore/JDBCStore tripping over its
own feet.
I think we can take this to the development mailing list for discussion, then
come back here with a solution + fix.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
