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

Transaction must be sticky to ensure consistency for EJB remote invocation with JPA

XMLWordPrintable

    • Hide

      Mail application which have a call sequence of

      • read
      • update
      • read
        done by remote calls to a different application.
        Deploy the 'background' application in a cluster with 2 nodes.
        The BG application contain a JPA entity and read/update the same attribute.
        If the main app is use, it will open a transaction by default and distribute that if the BG app is called. If BG app is accessed the first time it will read the entity on node1, the update will go to node2. But the next read will go to node1 again and because of the "per transaction" cache it will return the old value.
      Show
      Mail application which have a call sequence of read update read done by remote calls to a different application. Deploy the 'background' application in a cluster with 2 nodes. The BG application contain a JPA entity and read/update the same attribute. If the main app is use, it will open a transaction by default and distribute that if the BG app is called. If BG app is accessed the first time it will read the entity on node1, the update will go to node2. But the next read will go to node1 again and because of the "per transaction" cache it will return the old value.

      If an application inside of a server uses standard JavaEE persistence JPA, the current implementation include a local 1. level cache which might end in inconsistent reads within the same (uncommited) transaction.

      There are two reasons

      • JPA must not flush changes to an entity until commit
      • The 1. level cache might not read from the persistence if the entity is already loaded in a transaction

      Therefore the server to server invocations of EJB's need to be sticky to one node during a transaction. The granularity must be the application.
      It might be worth to use already known nodes for other applications as well.
      The stickyness should be enabled automatically if a transaction is active and distributed, which is the default within the current implementation, and use the loadbalancing policy if no transaction is active.

              tadamski@redhat.com Tomasz Adamski
              rhn-support-wfink Wolf Fink
              Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: