3 Replies Latest reply on Oct 16, 2003 6:34 AM by juha

    No new transaction started with RequiresNew

    joostdenboer

       

      "joostdenboer" wrote:
      "joostdenboer" wrote:
      Hi,

      I'm using JBoss 3.2.1 and notice the following:
      We have a simple application that uses a SessionBean. When a store-method is called, this calls 3 other methods in the same bean.
      The store-method has transaction attribute Required to guarantee a transaction is used. The 3 inner methods have transaction attribute Mandatory, RequiresNew and Mandatory. All is configured in ejb-jar.xml.

      --store-method : Required
      -- inner A : Mandatory
      -- inner B : RequiresNew
      -- inner C : Mandatory

      I turned on tracing on the org.jboss.tm package to see what JBoss is doing.
      What I expect is:
      - JBoss is starts a transaction before the store-method is call.
      - In this transaction perform inner A method.
      - Before inner B is called, the transaction is suspended and a new transaction is created
      - After inner B method, the current transaction is commited and the suspended transaction is resumed.
      - method C is performed in the transaction
      - the transaction is commited when the store-method has ended.

      However, what I notice is that JBoss is NOT suspending the current transaction and creating a new transaction before inner B is called although the method is configured with RequiresNew transaction attribute.

      Is this a known problem or is my expectation not correct ?



        • 1. Re: JGroups Configuration With XML Element

          Your XMLConfigurator changes added a bug, and it makes your changes unlikely to work.

          The try block at line 323 in the parse method that takes an Element as a parameter starts like this:

          try {
           Node root=null;
          
           NodeList roots=root_element.getChildNodes();
           for(int i =0; i < roots.getLength(); i++) {
           root=roots.item(i);
           if(root.getNodeType() != Node.ELEMENT_NODE)
           continue;
           }
          
           String root_name=root.getNodeName();


          Considering that the Element passed is likely the "config" element, this code would not work, and since the root node is always assigned regardless of its node type in the for loop, who knows what node you will end up with.

          I made the following changes in order to get the expected behavior:

          try {
           Node root=root_element;
          
          // NodeList roots=root_element.getChildNodes();
          // for(int i =0; i < roots.getLength(); i++) {
          // root=roots.item(i);
          // if(root.getNodeType() != Node.ELEMENT_NODE)
          // continue;
          // }
          
           String root_name=root.getNodeName();


          Can you commit this change (or something like it) to CVS?

          • 2. Re: No new transaction started with RequiresNew
            joostdenboer

             

            "joostdenboer" wrote:
            "joostdenboer" wrote:
            I've checked them multiple times. What could I have done wrong ? I only expect that I could have made a mistake in the ejb-jar.xml , but that one is correct.

            I modified the code so that the method which I want in a seperate transaction is in another sessionbean. This 2nd bean also has container managed transactions and I put the transaction attribute of the method also to RequiresNew.
            Now suddenly it works. The transaction started by bean1 is suspended, a new transaction is started before the method of bean2 is called, the transaction is commited after the method ends and the original transaction is resumed.

            So, in 2 different beans it works, but in 1 single bean it doesn't.
            Any idea why ?

            Joost


            • 3. Re: No new transaction started with RequiresNew

               

              "juha@jboss.org" wrote:
              "juha@jboss.org" wrote:
              Yes, you must not call bean's own remote methods directly from your bean implementation, rather you need to call context.getEJBObject() and invoke on the returned proxy. This guarantees the proper transaction and security propagation, etc.

              Calling the bean's other business methods directly from within implementation is incorrect.

              -- Juha