Yes, and my point is that your recommendation for a Jpa specific implementation only addresses (as far as I can tell, and maybe I read it wrong) whatever is already covered the automatic cleanup in the CentralAuthenticationServiceImpl.
Update is only called when a ticket is acted upon (in a number of ways). For the most part, those are already cleaned up by the CentralAuthenticationServiceImpl (i.e. if you validate a ticket, before you return, it checks isExpired and removes it if it is). Cheers Scott On Wed, Apr 29, 2009 at 11:23 AM, Marvin Addison <marvin.addi...@gmail.com>wrote: > > CentralAuthenticationServiceImpl [...] does what you want already > > If a TGT or Service Ticket is loaded and its found to be > > expired, its automatically removed. > > I understand that CAS cleans up expired tickets in cases where the > client presents the expired ticket. The RegistryCleaner component, on > the other hand, exists to clean up orphaned tickets. Clients can and > do disappear without a trace for a number of reasons. In the simplest > case the user simply closes the browser before their single sign on > session expires. Now CAS is stuck with a ticket in the registry, and > an out-of-band process like RegistryCleaner is responsible for > cleanup. It is that use case that I'm attempting to address. The > DefaultRegistryCleaner component is effectively broken for high > traffic sites with large numbers of orphaned tickets; my proposal is > an attempt to provide an out-of-box solution for those folks. > > M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
