To answer your #1 and #3, the key thing is to hold the WL for the minimum required time.
You only have to hold it long enough to:
a) Accurately determine if anything needs to be replicated
b) Copy that into the DTO that's passed to the replication layer.
c) Serialize attributes.
Ideally a) and b) can be combined into one very quick step, although that would take some
rework of logic. Then the WL could be acquired separately for c), which again should be
quick. So you don't want to hold the WL for the duration of the replication.
Hmm, although that somewhat defeats the point, which is to get a consistent snapshot of
the session. Separately locking for the serialization allows a request thread to sneak in
and change the state of an attribute value.
#2 is more of an issue. By relying on synchronizing on the facade, we're basically
giving priority to getting the replication out over consistency, and then letting the app
enforce consistency by synchronizing on the facade.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240463#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...