Yes, the TicketRegistry interface is clear. Deleted tickets must not
be returned by any get method.
After that, each implementation is free to remove or not element. If
it doesn't remove element, it has to flag
them and never return them.

Alex


2013/2/1 Fredrik Jönsson <f...@kth.se>:
> fre 2013-02-01 klockan 11:27 +0100 skrev Alexandre DE PELLEGRIN:
>> I agree with you. Or perhaps it's due to the audit module based on
>> AspectJ. Before activating this module, I didn't realize that.
>>
>> Before my migration to ehcache, I also lived two years with memcached.
>> I remember that nothing was evicted from the cache
>> and the delete seemed to do nothing. So, we used it just as a fifo cache.
>
> No, MemcacheTicketRegistry delete tickets when asked to, see snippet
> below, and it works fine. Unless TicketRegisty interface is broken, any
> TicketRegistry that returns a ticket on getTicket after a call to
> deleteTicket is broken. Any code that *depends* on a ticket registry
> returning a ticket after it's been deleted is broken. However, it may
> well call getTicket if it feels like for whatever purpose, nothing wrong
> in that, but should then handle the null it ought to receive.
>
>     public boolean deleteTicket(final String ticketId) {
>         log.debug("Deleting ticket {}", ticketId);
>         try {
>             return this.client.delete(ticketId).get();
>         } catch (final Exception e) {
>             log.error("Failed deleting {}", ticketId, e);
>         }
>         return false;
>     }
>
> This is really what concerns me with this. I get the not fully confirmed
> feeling that some ticket registries have developed weird behaviours
> outside the contract that other parts of the server has started to
> depend on and this sets of all sorts of alarm clocks with me.
>
> Like returning tickets that should have been deleted.
> Like calling expire on tickets on deletion.
>
> This is sloppy and will explode.
>
> Best regards,
> /Fredrik
>
> --
> You are currently subscribed to cas-dev@lists.jasig.org as: 
> depelleg...@essec.edu
> 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

Reply via email to