Jess Holle wrote:
Where have I "faked" robustness? I will not claim I actually achieve it, but I certainly tried, fixed real race condition cases, and don't know of ones I missed.

The only race condition that I can possibly imagine is on accessCount, which I think is something quite unimportant (if you think it is, add volatile which will solve the problem). We don't care about the exactitude of lastAccessedTime in this case (or you need to tell me why we care).


I will admit that I added complexity to base classes to support more robust operation of special purpose classes for session passivation. I loathed doing this, but did not see a good way to avoid this. As I recall if there was a single factory method for creating Session objects, then I could have just subclasses StandardSession and done everything in more derived classes -- leaving ManagerBase alone. I'd like that much better. Unfortunately, a static analyzer showed other usages of StandardSession's constructors. If I am in error on this, I'd be more than happy to rectify this!

Right, and next time there's an issue, we'll add postAccess, I suppose. This is not workable.


[The change to Request is necessary in any case I can see, however -- unless a much higher level, and thus more expensive, synchronization is done between normal session access and passivation.]

You need to relax a little about this kind of issues. The rest of your patch seems like a good start overall :)


Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to