> 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
