Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-5537

Singleton EJBs with multiple views does not honor Lock semantics

    Details

    • Steps to Reproduce:
      Hide

      Deploy above code example in WildFly.

      Let another component call the sayHello method.

      ( do it in an Arquillian test fx ).

      Sometimes the method invocation will throw up ! sometimes it will not.

      Show
      Deploy above code example in WildFly. Let another component call the sayHello method. ( do it in an Arquillian test fx ). Sometimes the method invocation will throw up ! sometimes it will not.
    • Affects:
      User Experience

      Description

      Upon method invocations to Singleton EJBs with multiple views... the ContainerManagedConcurrencyInterceptor randomly selects a wrong Lock (READ / WRITE).

      Here is an example:

      @Singleton
      @Lock(LockType.READ)
      @Local({ GreeterSayMyName.class, GreeterSayHello.class })
      public class GreeterBean implements GreeterSayMyName, GreeterSayHello {
       
          @EJB
          GreeterSayMyName myself;
       
          @Override
          public String sayHello() {
              return "hello from " + myself.sayMyName();
          }
       
          @Override
          public String sayMyName() {
              return "The Greeter";
          }
      }
       
      public interface GreeterSayHello {
          
          String sayHello();
          
      }
       
      public interface GreeterSayMyName {
       
          String sayMyName();
       
      }
      

      Sometimes (randomly) invoking the 'sayHello' method on this example EJB causes lock upgrade exceptions. They look like this:

      13:14:10,436 ERROR [f2PtkwmdRgaoHCdnZ7Vurg] [anonymous] [org.jboss.as.ejb3.invocation] (default task-5 f2PtkwmdRgaoHCdnZ7Vurg) WFLYEJB0034: EJB Invocation failed on component GreeterBean for method public abstract java.lang.String hello.world.GreeterSayHello.sayHello(): javax.ejb.IllegalLoopbackException: WFLYEJB0238: EJB 3.1 PFD2 4.8.5.1.1 upgrading from read to write lock is not allowed
      	at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.checkLoopback(EJBReadWriteLock.java:232)
      	at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.access$300(EJBReadWriteLock.java:40)
      
      

      This happens completely randomly.

      The problem is that the interceptor only knows about one of the views' methods. At deployment time the ViewService will start the views concurrently - and the interceptorfactory only adds an interceptor instance to the interceptor context if one does not already exist.

      When the exception does NOT occur -then there is still a problem (although not visible from the code): A WRITE lock is selected - even though , given the above code, it should never ever be possible. So in fact - the issue , in that case, does not cause an exception because .... it already has the WRITE lock.

      ( When the exception occurs ...then it is because the sayHello() invocation resulted in a READ lock ... and the reentrant invocation caused a WRITE lock to be selected by the interceptor ... but as this is not allowed, it results in a horrible exception )

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  swd847 Stuart Douglas
                  Reporter:
                  nmoelholm Nicky Mølholm
                • Votes:
                  4 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: