Details
-
Type:
Bug
-
Status: RESOLVED
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: 2.4.0, 2.4.1, 2.5.0, 2.5.2, 2.5.3, 2.5.4, 2.6.0
-
Fix Version/s: None
-
Component/s: Cluster service (Pre-K1/2.6), Presence
-
Labels:None
Description
Because user session closing is not an atomic transaction, it's possible for interrelated tables to get out of sync, which in turn requires periodic cleanup.
Currently this is being handled by a maintenance loop in the Cluster service. Its 2.4.0-era logic incorrectly assumed that all debris could be found by finding session records which needed to be closed and then closing them. SAK-9857 describes a fairly common case in which SAKAI_LOCK records left over from an otherwise closed session were being missed.
Cleanup of SAKAI_PRESENCE records depends on similar logic, and so they also seem to be missed occasionally. In a properly maintained system, SAKAI_PRESENCE's SESSION_IDs should point to a subset of active session records. In our production database, I find 11 SAKAI_PRESENCE records referring to closed sessions ranging in time from February to mid-August 2007.
Something along the lines of the SAK-9857 fix also needs to be implemented for SAKAI_PRESENCE.