[jboss-dev-forums] [Design of JBossCache] - Re: Listener Notifications to happen asyncronously?

[bstansberry@jboss.com]

We're not just forcing the use of a different thread; we are changing the timing of the notifications.  

For readers, these are some differences in 2.0.0.CR2 vs. the 1.x releases:

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.

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.

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.

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.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057137#4057137

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057137