0000821: persistent session enhancements

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0000821

[Resin]

minor

always

01-06-06 10:02

02-01-06 11:14

Reporter

ferg

View Status

public

Assigned To

ferg

Priority

high

Resolution

fixed

Status

closed

Product Version

3.0.17

Summary

0000821: persistent session enhancements

Description

(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
modules/resin/com/caucho/server/session/SessionImpl.java.

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
talking about.

Additional Information

Attached Files

Relationships

Notes
(0000830) ferg 02-01-06 11:14	server/01k9

Issue History
Date Modified	Username	Field	Change
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[^]

28 total queries executed.
25 unique queries executed.