3 Replies Latest reply on May 9, 2009 9:32 PM by skajotde

    Persistence context propagation on remote calls

    adamw

      Hello,

      if I call a remote bean (transaction is propagated), which happens to be deployed on the same JVM (same JBoss, same ear even), will the PC be propagated?

      I know of two rules governing PC propagation:
      1. a PC is not propagated on remote calls
      2. a PC is propagated along with the transaction

      and I thought that the 1st rule always takes precedence - that is, whenever there's a remote call, the PC is not propagated. But I just saw a case in JBoss (4.2.3, Hiberante 3.3.1), where this was not so: the PC was propagated, although the call is remote (but in the same application).

      So is this a whole in the spec, a bug in JBoss EJB3, or is the PC not propagated on remote calls only when the call is "really" remote? (meaning that you couldn't really rely on the PC being propagated or not in your bean)

      Adam

        • 1. Re: Persistence context propagation on remote calls
          wolfc

           

          "EJB 3.0 Persistence 5.6.3" wrote:
          Propagation of persistence contexts only applies within a local environment. Persistence contexts are not propagated to remote tiers.

          So propagation will not occur if the call is really remote. Calling locally through a remote interface will propagate the PC.

          • 2. Re: Persistence context propagation on remote calls
            adamw

            I see ... so I would say it's a hole in the specs ;)

            If I use a bean via its remote interface, I think where the bean is deployed should be really completely transparent to the programmer - and it isn't as it matters if the beans are deployed together or not. (The code may execute differently if the PC is propagated or not)

            Adam

            • 3. Re: Persistence context propagation on remote calls
              skajotde

              To simulate remote behaviour you can put remote interfaces in additional ear and configure isolation for this ear (default is local).

              I found additional situation: attribute mappedName, it is a pity that semantics of global name resource (global in some context) is not standardised.