We are using jboss cache as second level hibernate cache. It is configured to evict changed entities asyncronously. But this feature does not work for us. Some debugging revealed the root of the problem.

When treecache accessed, it adds itself as transaction listener. This is done by adding Synchronization to active transaction inside org.jboss.cache.interceptors.OrderedSynchronizationHandler (see getInstance() method). Hibernate adds itself too when session created.

In usual case ejb access to entities from hibernate first, and then hibernate accesses tree cache as its own L2 cache. So hibernate sync registered first and tree cache registered second.

In our case first accessed tree cache for storing information about ejb calls, and only after that hibernate session created. So tree cache sync became first. It does not matter that availability tree cache is not hibernate tree cache -- they both are using same synch (see OrderedSynchronizationHandler.getInstance implementation).

So when transaction committed, tree cache synch called first. And here comes to play tree cache configuration quality -- if async replication or invalidation used, cache triggers it on transaction prepare phase -- i.e. in beforeComplete method of Sync. But as hibernate sync placed after tree cache's sync, it had no chance to see any changes to replicate. And in beforeComplete method tree cache replicates no changes!

The current solution for us -- place working with tree cache to separate transaction. But this solution need programmers to remember about placing some tree cache calls into separate transaction.

Does anybody faced this problem too? Is there another solution?

Do you use JTA approach or plain JDBCTransactionFactory in Hibernate configuration?
(Be aware of the fact that JbossCache as 2L cache for Hibernate requires integration with JTA)

JTA integration is used. Actually replication works fine, if availability tree cache used from separate transaction.

I would try migrate to Infinispan which is the successor of JBossCache.
Maybe there the problem does not exist (and Infinispan should be faster than JBossCache )

Actually our team tied to old JBoss version (4.2), where AFAIK Infinispan is not available