One possibility is that notifications are only made when changes are made to the cache directly. Optimistic locking creates a layer - a 'workspace' - on which changes are applied to until transactions commit.
Do you have any ongoing transactions (perhaps CMT) at the time, which may not be committed till later?
Also, is it the case that you don't see any notifications, or do you only see the notifications later rather than when you make your mods on the cache?
We have stepped through the JBossCache code and these are our findings-
1. Optimistic locking does bring a layer of transaction workspace in between. However, the TransactionWorkspace takes care that the entries are added in the tree data structure starting from the root of the cache. Thus TreeCache_put() methods are actually bypassed during optimistic locking.
2. Even when the transaction is committed, the _put() methods are not called since the tree data structure already contains the node.
Note that in the JBossCache code, notifyNodeModify() and notifyNodeModified() methods are *ONLY* called from the _put() methods of TreeCache and nowhere else. Thus with Optimistic locking, modify notifications are *never* made to the tree cache listeners. The listeners receive notification for node creation but that is not useful because data corresponding to the FQN would be null
3. It is also observed that if i put data in cache1 which is replicated to cache2, the listener for cache2 is notified about node creation. However, when i try to get the data from cache2, I get null. Can you explain this?
Unless this was intentional, we feel that this may be a bug in the JBoss cache code.
Unless you have a workaround for this, I guess we will have to use Pessimistic locking with our own versioning for the data.
Thanks and Regards,
I have just added a unit test around this and this seems to receive notifications just fine. While this is in HEAD and not the 1.3.x branch, none of the notification or optimistic locking codebase has changed between 1.3.x and 1.4.x.
Do you still see this problem when using a release from 1.4.x?
Regarding point #3, again we have unit tests that prove that this works. Is it possible that your listener is throwing an exception or in some way blocking the call from completing?
I saw the testcases u tested, I see that you used TreeCache , I am facing problems with TreeCacheAop as cache.
If you could please check with TreeCacheAop, with which I am facing problems, of the listener not getting notified with optimistic locking enabled.
I also checked it with latest version 1.4.x but was having some other problems with it.
Thanks and Regards
How do use TreeCacheAop since TreeCacheAop just sub-classing from TreeCache now, I'd expect the behavior should be the same.