"bstansberry(a)jboss.com" wrote : | 1) Notifications are dispatched in a separate thread, and the thread that caused the notification does not block waiting for the notifications to finish. Thus, by the time the notification is received the cache could have processed numerous other changes. I could also conceivably get a notification for a node from change 1 after I get a notification for change 2. | Yes order is an issue, there is another thread I brought up which talks about the need for further changes to solve ordering problems. We should also be able to maintain TX order through use of a blocking queue. At the moment change order within a TX is guaranteed, which is a must, but the interleaving problem I described in the thread could still occur. http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054779 anonymous wrote : | 2) All notifications for events that occur within a transactional context are dispatched as part of tx commit. And again, the calling thread doesn't block. Also, the transactional context is not associated with the notification thread, so if my app wanted to do transactional work as part of the notification, that won't work. Even if the tx context were associated with the notification thread, the tx is in the commit phase so it can't be used. | This was a change that was made earlier (before introducing the thread pool). The problem is that optimistic locking and pessimistic locking had completely different behaviors. Optimistic locking sent notifications on transaction commit. Pessimistic locking would send notifications even if a transaction was rolled back, and in that case would also send undo notifications. Also, the cache listener code was not designed to handle reentrancy. So if you tried to make changes when receiving a notification, it could lead to all kinds of problems. Specifically, there are issues with the fact that the TX has already been committed. anonymous wrote : | 3) I believe the notifications are issued after locks are released. So, even if the main thread blocked while the notifications were done, the listener would have no guarantee that some other thread hasn't altered the cache state. | Right, this is why the cache listener is passed the state of the node at the time of the change. See the thread I mentioned about, I had suggested merging pre and post to make accessing this easier. This still poses a problem for me though, because for pojo notifications, I need to hit the cache when processing a notification, since I don't have all of the state available (object references to other nodes). anonymous wrote : | I'm not sure if a notification is much use to me if I can't rely on the timing of the notification with respect to the state of the cache system. Getting tx notifications at commit could possibly be OK if #3 were solved, but #1 is a big problem. | | Note that a major use of notifications is to make app code aware of remotely originating modifications to the cached data. There's no other convenient mechanism for this code of cluster-wide signalling. The ordering issues can be solved, the ability to intercept and modify cache state during any modification is not possible with the current design. For that to work we would essentially need them to be more like a database trigger than a notification. So in both the pessimistic and optimistic locking scenarios, the callbacks would have to occur after each change regardless of the success of the transaction. or this to occur we would need to make the cache interceptor stack reentrant. Also, This would mean that app listeners would have to be able to handle changes that never committed. To be honest this type of design would be easier for me to map for POJO cache, however it conflicts with the goal for notifications to be sent only when the tx is committed. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057204#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...