Remy Maucherat wrote:
Jess Holle wrote:
It is not useful without the rest of the changes as without the rest of the changes there are intolerable race conditions.
Right. I suppose that's the end of the discussion then, it would be a waste of time to continue. -1 for your patch.
If you really feel insecure, then you could try adding volatile to the accessCount field, but it's really useless.
Volatility of accessCount is a minor (though perhaps additionally necessary) part.
The bigger issues are that:
* During a request, between getSession(sessionId) and
session.access() the session could be passivated and recycled --
thus lousing up that request.
* A truly long request (e.g. a streaming dynamic content response)
can be ongoing and have its session passivated and recycled while
it is still ongoing -- recycling the session object it already has
access to.As I recall there were other race condition possibilities, but these by themselves were too problematic to let alone.
If anyone is actually able to get any robust value out of PersistentManager as it is, then I believe my changes to the passivated session expiration algorithm are a good thing. I just don't see how the whole thing is supposed to really hold water with known race conditions (including a "FIXME" noting them...)
-- Jess Holle
