Remy Maucherat wrote:
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issues in this area of the code that I cannot ignore if I am to depend on PersistentManager.
* Extremely inefficient behavior when trying to expire passivated
sessions.
o All passivated sessions were fully deserialized back into
memory to check if they were stale upon each and every
processExpires() execution. For large numbers of large
sessions (the whole reason you'd bother with passivation!),
this will be a large drain on performance.
o My changes make the modification time more accessible in
FileStore and make more efficient staleness checks in both
FileStore and JDBCStore.
This seems useful.
Additionally there was a discrepancy between lastAccessedTime and thisAccessedTime usage in normal isValid(), etc, and the behavior of PersistentManagerBase, etc
In all of these cases I may have misunderstood something or overlooked more optimal solutions. I would like to see all of these issues addressed in the best fashion possible -- and if possible in the standard distribution of Tomcat rather than just in ours. I am thus more than open to suggestions for improvement. The issue is that right now there are clear, unaddressed issues which I believe I have at least improved upon though certainly not perfected.
As I said:
I don't like the foundation on which the patch stands, unfortunately. I also don't quite see the real-world usefulness of some of the new features, for example the date usage sorting.
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.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
