+1 that the suggested changes to JTA are good. But, not likely to happen in time for AS
4.2, so... ;-)
TransactionSynchronizationRegistry.put/getResource could *possibly* be used to communicate
information between Hibernate and JBC. But in any case, it's a JEE 5 feature and JBC
as a 2nd level cache needs to work in legacy environments.
Synchronization ordering a la what JBC does should be possible, although ugly. Please
have a look at class org.jboss.cache.interceptors.OrderedSynchronizationHandler to get a
better feel for how JBC does this. Basically, any time JBC wants to add a
Synchronization, it:
1) Calls the static OSH.getInstance(Transaction) method.
2) OSH looks up the tx in a Map<Transaction, OSH>; if an instance is found it's
returned; if not one is created, put in the map and returned.
3) JBC adds the new Synchronization either at the head or the tail.
4) In the afterCompletion() callback, the entry for the tx is removed from the map.
A solution to the ordering problem would be:
1) Hibernate creates it's own version of OSH. Called here HOSH, with the JBC version
now called JOSH.
2) When Hibernate registers synchronizations, it follows the same process as above, using
HOSH.
3) TreeCache/OptimisiticTreeCache provide the integration. When a call is invoked with a
transactional context, they:
a) Call HOSH.getInstance(tx).
b) Call JOSH.getInstance(tx).
c) Add the JOSH at the tail of the HOSH.
Effect of this is that all JBC synchronizations will execute after any Hibernate
synchronizations that were already added to HOSH. *Assuming* the required Hibernate
synchronizations are added before the first call to TreeCache/OptimisticTreeCache, this
should work.
One thing I haven't given much thought to is any possible classloader issues.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993557#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...