|Anonymous | Login | Signup for a new account||10-03-2023 03:20 PDT|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Advanced Details [ Jump to Notes ]||[ View Simple ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000821||[Resin]||minor||always||01-06-06 10:02||02-01-06 11:14|
|ETA||none||Fixed in Version||3.0.18||Product Version||3.0.17|
|Summary||0000821: persistent session enhancements|
(rep by Mark Adams)
I have been playing with 3.0.17 for a few days now, and I haven't
gotten it to give me any problems with lost sessions. That's good
news, though I wasn't ever that good at reproducing the customers'
intermittent problems with 3.0.14, either. I did notice, though, that
it does seen to save persiststent sessions quite a bit more often than
it needs to. There are a couple of causes for this, in
First, the load() method calls unbind() and then re-sets all the
attributes, thus ensuring that the corresponding ClusterObject will be
marked as changed.
Second, in the setAttribute() method, the old and new values are
considered to be different if they're different instances (o1 !=
o2), which will essentially always be true, since the new values were
created by deserializing the session data from the database. Testing
for object equality (o1.equals(o2)) would be more accurate.
Third, there's a check in ClusterObject.store() that's supposed to
short-circuit the database write if the new CRC of the serialized
session data is the same as the CRC of the data that was loaded.
However, SessionImpl.store() is nondeterministic about the order in
which it serializes the session attributes: it simply iterates over
the _values HashMap's entry set. Since the attributes don't necessarily
get serialized in the same order in which they were deserialized, you
end up with spurious differences in the CRCs and you end up doing the
database write when you don't need to.
I'm attaching a version of SessionImpl.java that contains some fixes
that I made for these 3 issues. It's based on the 3.0.17 version of
the file. I don't promise that my approach is optimal, or even correct
for that matter, but hopefully it'll help to illustrate the issues I'm
|Steps To Reproduce|
|01-06-06 10:02||ferg||New Issue|
|02-01-06 11:14||ferg||Note Added: 0000830|
|02-01-06 11:14||ferg||Assigned To||=> ferg|
|02-01-06 11:14||ferg||Status||new => closed|
|02-01-06 11:14||ferg||Resolution||open => fixed|
|02-01-06 11:14||ferg||Fixed in Version||=> 3.0.18|
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
28 total queries executed.|
25 unique queries executed.