Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at this moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
Sorry I missed your previous comments somehow. I've included them below:
I did not get a warm fuzzy "this is rock solid stuff" feeling about this myself...I don't like the foundation on which the patch stands, unfortunately.
That said, if there are problems with the foundation, then let's rework it. In the end, I did not see too much glaringly awful about the approach.
I unfortunately need session passivation, so if necessary I'll have just keep this in my own distribution if that's what it takes. I am guessing I'm not the *only* one in this boat, so it would be good to work this out...
If you have a limit on the maximum active sessions and many more sessions than this (when non-expired, passivated sessions are included) then it makes sense to have a fairly aggressive minimum idle time prior to passivation but to ensure that the oldest non-passivated session will be passivated first so as to avoid thrashing between active and passive states where it is not necessary.I also don't quite see the real-world usefulness of some of the new features, for example the date usage sorting.
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.In particular, all the proposed changes to the base classes (std session, manager base, request), which seem to be designed to add fake robustness to the mix, and add more complexity. I don't think any of these changes bring anything useful, but they do decrease performance and maintainability.
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!
All the same the changes to the base classes are fairly minimally obtrusive. If they cannot be avoided, then they seem worth living with for some of us to have session passivation...
[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.]
-- Jess Holle
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
