[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa

[bstansberry@jboss.com]

"smarlow at 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.

"smarlow at 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