> We have a clustered environment, so I think I'll setup a cronjob to run that > sql line.
Running that line at any other time than an orphaned lock condition runs the risk of damaging lock state in such a way that concurrent execution of cleanup may occur, which is the whole purpose of database-backed locking strategy. I would strongly advise against this. We've been running this code in our production environment for months now and have had zero problems other than redeployments, where it's reasonable to execute that SQL statement as part of post-deploy process. I'd encourage investigating how the database got in this state in the first place before attempting other workarounds. > Just one more thing.. When this "error" occurs is it normal that CAS returns > a error message to the users (not even showing the authentication page)? It's strictly informational, and it is logged at INFO to help clarify that's it part of normal operation. Ticket cleanup has absolutely no impact on CAS availability, so if you're getting error messages on the front end when that occurs, there's something else going on. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
