We are not doing any proxying, so in reality, that column should be null? Like I said, this process seems to have been working before we implemented throttling. I'm not sure why thought it started happening around that time.
Can anyone tell me the referncial integrity between the SERVICETICKET and TICKETGRANTINGTICKET tables? We are planning on dropping these 2 tables and recreating them to clear out the data, and then have a script to clear these out every day, but the DBA's were asking about the RI between these two tables. Also, so that TICKETGRANTINGTICKET_ID column is only used if using a proxy? Thanks! -----Original Message----- From: Marvin Addison [mailto:[email protected]] Sent: Thursday, April 17, 2014 10:39 AM To: [email protected] Subject: Re: [cas-user] TGT table not getting cleaned up > DELETE > FROM TICKETGRANTINGTICKET > WHERE ID=? The ticket cleanup task is known to be poorly optimized. Note that it's issuing a per-ticket delete _after_ loading all tickets into memory. That's likely unworkable for the number of tickets you mentioned (4M). If you're having trouble simply schedule a job to delete any tickets idle for more than, say, 24 hours: DELETE FROM TICKETGRANTINGTICKET WHERE LAST_TIME_USED < 24_hours_ago; (The way you compute 24 hours ago is a platform-specific detail.) You'd choose a more conservative TTL if you're using remember me. > Is the TICKETGRANTINGTICKET_ID supposed to be null? I’m thinking it > should not. It's probably more likely to be null than not unless you do a lot of proxying. That's a foreign key used to create a ticket graph; for example CAS proxy support. 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 -- 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
