|
Mantis - Resin
|
|||||
| Viewing Issue Advanced Details | |||||
|
|
|||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 821 | minor | always | 01-06-06 10:02 | 02-01-06 11:14 | |
|
|
|||||
| Reporter: | ferg | Platform: | |||
| Assigned To: | ferg | OS: | |||
| Priority: | high | OS Version: | |||
| Status: | closed | Product Version: | 3.0.17 | ||
| Product Build: | Resolution: | fixed | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 3.0.18 | ||
|
|
|||||
| 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. |
||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Relationships | |||||
| Attached Files: | |||||
| Notes | |||||
|
|
|||||
|
|
||||