"jason.greene(a)jboss.com" wrote : "manik.surtani(a)jboss.com" wrote : 1.
Even with using a thread pool, notifications for each call or transaction are performed by
the same thread (see Notifier.invokeQueuedNotifications()) - a single Runnable is used to
loop thru all registered listeners, for all registered notification events. So you will
get pre and post events in order, and not concurrently.
| |
|
| Yes, but the listener instances are shared across all threads, so there could be two
runnables running at the same time (unless the pool size is 1). Alternatively the pre and
post phase could be combined to one method call with the before and after data.
|
Hmm, or did you mean using the thread-id for correlation? If so that would work (provided
there is a tx start stop), but that ties the implementation of notification delivery to
single thread semantics. Having a tx id or some kind of special change id would allow for
future threading behavior changes. This is of course assuming that others using the the
CacheListener API want to do similar things.
-Jason
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054786#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...