11 Replies Latest reply on Apr 25, 2012 5:42 PM by j4m3s

    @SessionScoped @Stateful Bean - why are ConcurrentAccessExceptions even possible?

    j4m3s

      I'm using JBoss 7.1.0.Final.

       

      I've managed to track-down an issue I'm having to (I think) a javax.ejb.ConcurrentAccessException.  I say "I think" because the exception I get is actually an IllegalStateException when I make the next call to the SFSB (by which point the instance has been removed from the session).  With loging turned-up to ALL I can see the following entry (though this exception never appears in a stack trace):

      {code}18:41:46,408 TRACE [org.jboss.modules:204] (ajp--127.0.0.1-8009-6) Finding local class javax.ejb.ConcurrentAccessException from Module "javax.ejb.api:main" from local module loader @5328f6ee (roots: /usr/local/jboss/current/modules) {code}

        I know I'm making multiple concurrent calls to a RESTEasy service, which in turn uses a weld-injected, session-scoped SFSB to access an in-memory financial model.  (The concurrent calls are being generated by AJAX calls on the client-side).

       

      What I'm struggling to understand is how I can be generating the exception.  I thought all calls to stateful beans were serialized by weld? 

       

      What I've done, to try to serialise further, is add a java.util.concurrent.locks.ReentrantLock to my session bean.  When I receive a call into the @Stateless bean that performs the RESTEasy work, I get the lock from the (@Inject'ed) SFSB and call lock.tryLock() before calling any further methods on the SFSB or the @Entity's that I retrieve from it (and finally I release the lock with lock.unlock() ).  I'm happy to explain more why I'm doing it but briefly I'm using the Persistent Data Object pattern and an Extended PersistenceContext in the SFSB (as suggested by Adam Bien and used to great success by Jan Groth according to this thread: http://stackoverflow.com/questions/6348180/stateful-ejb-with-extended-persistence-context-to-handle-user-session).

       

      I can only assume that it's the fact that I'm getting this Lock object from the SFSB then calling tryLock is the source of my problem.  But I don't understand why I get the ConcurrentModificationException in the first place - or what else I could do to avoid the problem.

       

      Thanks in advance - I've been battling with this for days and have tried installing solder, seam 3 persistence and all sorts of other things to fix it

       

      Regards, James.

       

      Message was edited by: James Fellows - Exception details updated