"smar...@redhat.com" wrote : Brian,
|
| We will have to try to get access to the StandardSessionFacade from there
as well (perhaps through the ClusteredSession).
|
|
Yes. The tricky bit is if there are multiple sessions being replicated (as part
of a cross-context request.) See below for more.
"smar...@redhat.com" wrote :
| anonymous wrote :
| | The concern I have is StandardSession.facade is not thread safe, and
what's returned from getSession() needs to be if we are going to use it as a
mutex.
| |
| We will only synchronize on the StandardSession.facade object and not
modify it. Since we are not modifying the StandardSession.facade object, we do
not need it to be thread safe. At least that is my thinking, let me know if
I'm missing something :-)
|
|
Sorry, I wasn't clear. The concern I have is concurrent requests to
getSession() resulting in 2 facades being created. The classic singleton
"getInstance() method" concurrency problem, except here it's not a static
field. If you're going to lock on the facade you need to make sure there is
only one facade. The current getSession() method doesn't do that.
anonymous wrote :
| There's no ref to facade outside StandardSession.getSession(), so
ClusteredSession can override the getSession() method and replace the field
with a volatile field and synchronize the construction if null.
|
What I described above is probably way overkill. Perhaps just calling
getSession() in the constructor to ensure the field is initialized will work.
Seems my last post was misformatted and got cut off. Further to the AS 5
discussion, in the future it's possible the serialization will happen on a
different thread. (Infinispan was looking at putting replication messages in a
queue and then having seperate threads process them, including serialization.)
If that were the case, using a synchronized block around the
ClusteredSessionValve's tm.endBatch() call won't work.
But, the thing that actually gets serialized is an
org.jboss.ha.framework.server.SimpleCachableMarshalledValue. A possible
solution is to change that class to optionally pass in a "MutexSource" to its
constructor:
| public interface MutexSource {
|
| public abstract Object getMutex();
|
| }
If a MutexSource is available, SimpleCachableMarshalledValue.serialize() would
call that method and synchronize on the return value. ClusteredSession would
implement MutexSource by returning the result of a getSession() call.
This would also deal with the cross-context request issue noted above.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240155#4240155
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240155
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
