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

Wrong handling of request context for remote EJB calls

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 10.0.0.CR5
    • 9.0.0.Final, 10.0.0.CR4
    • CDI / Weld, EJB
    • None

    Description

      Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but all request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.

      A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.

      If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.

      I don't know the spec but:

      • either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
      • or each invokation must get its own request context (entity manager must be produced and disposed again).

      I've made a stackoverflow thread which shows some code examples.

      (JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s')

      Attachments

        Issue Links

          Activity

            People

              mkouba@redhat.com Martin Kouba
              ste_gr Stefan Gr (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: