I agree. I was just explaining why it was there :-) On May 30, 2014 4:19 PM, "Marvin Addison" <[email protected]> wrote:
> > We put them on CASImpl because technically that is where the transaction > > would occur (a single method on that class could call multiple > > ticketregistry methods) > > Correct, but clearly that approach has some undesirable side effects. > The only registry that would benefit from @Transactional on the > CASImpl methods is JPATicketRegistry; all other backends are not > transactional across multiple calls if they have transactional support > at all. > > My opinion is that TicketRegistry has outlived its usefulness. I > believe we would be better served by a generic StorageService facility > (get/put/delete) that has @Transactional on its methods as needed for > the JPA implementation. With a careful design of the semantics of > get/put I'm confident we could provide secure ticket storage without > the side effects that Andrew reported. Additionally, this approach > would naturally isolate dependencies into technology-specific modules > (JPA, Ehcache, memcached, LDAP) and hopefully reduce the number of > components. > > In any case it's probably not as easy as simply dropping > @Transactional on CASImpl for the reasons you cited, but with some > deeper changes to our storage subsystem I believe we can have a > win/win. I think a Jira issue citing the problem and solution Andrew > noted would justify further research and development work in that > direction. > > 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
