Yes, the ordering is registration order. The OSH API allows addition of a new Synchronization at the head or the tail of the current list. Something like you suggest where Hibernate can directly control this certainly seems preferable to my OSH hack. There are some problems with overloading TransactionManagerLookup with this behavior though: 1) With EJB3 in the AS, Hibernate *does not* create the JBC instance and thus doesn't inject the TM lookup. This is because the cache is a shared cache that pre-exists the EJB deployment. See o.j.ejb3.entity.TreeCacheProviderHook. Perhaps this should be changed, although that should probably be discussed on a separate thread. 2) The JBC TransactionManagerLookup interface is part of the public API. Adding methods to it breaks API compatibility. A subinterface with the extra methods is possible, but starts to get ugly. 3) In an IOC container like AS 5, TransactionManagerLookup is unnecessary, at least if the cache is built by the IOC container. In such a case the TM should be directly injected. JBC 2.0 supports both direct injection and the lookup. Overloading the lookup with new behavior forces the use of the lookup. There is some debate on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97236 as to whether JBossTS will be used in 4.2. If it won't be, that opens up the possibility of making this a JBC 2.x-only fix. There we have more freedom to alter the API to handle this cleanly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993907#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...