David, thanks for taking the time to consider the patch. > If the ticket read, expire check, and delete are not in a single > transaction, couldn't the cleaner delete a ticket that had just been renewed > (if the expire check is based on most recent use)?
No, not in a way that would be unexpected or incorrect. Let's assume the TimeoutExpirationPolicy is applied to TicketGrantingTickets, which would satisfy your criterion of updating the TGT on most recent use. The only way to update its state would be through CentralAuthenticationServiceImpl#grantServiceTicket(), which is @Transactional. The only relevant case I can imagine would be where RegistryCleaner#clean() fires and immediately afterward a TGT requests to grant a ST the instant before it expires. The outcome would be be dependent on which method got to the database first, and the behavior would be as expected. If the cleaner got there first, the ticket might appear expired and would be deleted. The grantServiceTicket() queries would block until the ticket were deleted, and would likely throw exceptions that would be caught indicating the ticket had been removed from the DB by another process. In the other case, where grantServiceTicket got to the database first, since it is transactional as well as JpaTicketRegistry#updateTicket, the cleaner process would block until the data was committed and the expired check would indicate the ticket was not expired. Hopefully it's clear that the above case is _very much_ an edge case since the proposition is that the ticket is infinitesimally close to its expiration date upon the attempt to generate the ST. M -- 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
