[ https://jira.jboss.org/jira/browse/DNA-541?page=com.atlassian.jira.plugin... ] Brian Carothers commented on DNA-541: ------------------------------------- The final piece is the ability to add a timeout for session-scoped and/or permanent locks. This would allow the system to clean itself up if sessions get closed without calling logout or a coding error results in lost lock tokens for permanent locks. Randall and I had an IRC discussion about this months ago where he suggested adding an expiry time to the lock record in /jcr:system/dna:locks and adding a thread that would periodically advance the time into the future for active sessions. The tricky part is determining which sessions are active. I was thinking about having each session create a ScheduledFuture task that would advance the expiry time for its own locks (if the session still existed), but I think it would be easier to just put a set of weak references to active sessions into the JcrRepository. The algorithm would then be something like this: let M := the repository's set of active sessions for each lock L under /jcr:system/dna:locks if (L.isSessionScoped) if (L.lockExpiration < the current time) delete L from graph delete corresponding lock from WorkspaceLockManager else if (M.containsKey(L.sessionId)) L.expiryTime += some interval There would probably have to be some balancing in there between the frequency at which this task runs and the amount that the expiry time is advanced to handle things like clock-drift across a cluster or the task running behind on heavily loaded systems. Any thoughts or feedback on this approach would be appreciated. My big questions are: 1. Is this even worth doing? 2. If it is worth doing, where should the scheduler (presumably a ScheduledExecutorService) live? That's the kind of service that the DNA repository has provided to the JcrRepositories in the past, I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-541?page=com.atlassian.jira.plugin... ] Brian Carothers updated DNA-541: -------------------------------- Attachment: DNA-541_admin_unlock.patch Those are good calls. Attached is a patch that implements lock expiration based on the algorithm above modified by Randall's comments. The patch includes two tests to confirm that the functionality works, but one is @Ignored because it depends on garbage collector behavior to test the results and the other is @Ignored because it has to sleep for 30 seconds to test the timeout. If the patch looks ok, I will commit it and resolve the defect. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-541?page=com.atlassian.jira.plugin... ] Brian Carothers updated DNA-541: -------------------------------- Attachment: (was: DNA-541_admin_unlock.patch) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-541?page=com.atlassian.jira.plugin... ] Brian Carothers commented on DNA-541: ------------------------------------- Responding point-by-point to the previous comment: 1. Good call. I've also added startup and awaitTermination to clean up the start-stop behavior with the new service. 2. Good call. Is it sufficient to wrap the three accesses to the activeSessions map in synchonized (this.activeSessions) { ... }? If not, I promise to go buy a copy of JCIP and read it over Xmas break. 3. Yeah, I'll add a comment on that one. The WLM's execution context is used only when performing actions outside the scope of the session. In general, I'm still trying to use the relevant session's context in case we ever start leveraging SSO more fully and use the session's JAAS subject and privileges to broker access to underlying repositories (which some incarnation of the jcr:system branch may rely on). Let me know if you want me to standardize on using one context or the other. Thanks for the great feedback! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-541?page=com.atlassian.jira.plugin... ] Brian Carothers resolved DNA-541. --------------------------------- Resolution: Done Committed patch to resolve defect -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira