Problems with multiple connections in the same transaction

Question

Hi all !
          I'm have two questions regarding the way weblogic handles multiple
          connections.
          1) first, I don't understand why weblogic always create a new Managed
          Connection when I'm asking for 2 connection handles on the same connection
          factory and with the same connectionRequestInfo. Isn't it supposed to share
          connections ?
          For instance, the following snippet of code results in the creation of 2
          managed connections:
          ConnHandle conn1 = myCF.getConnection(myRequInfo);
          ConnHandle conn2 = myCF.getConnection(myRequInfo);
          The class corresponding to myRequInfo does implement the equals and hash
          method, so that weblogic's connection manager could use them to check that
          the queried connections are the same, and thus could share a single
          ManagedConnection between multiple connection handles. Apparantly it does
          not do that...
          2) OK, I just let weblogic create the 2 managed connections, but... My use
          of the connections is as part of a transaction. Here is what happens:
          ConnHandle conn1 = myCF.getConnection(myRequInfo);
          // a new managedConn1 is instanciated. the following happens (just a
          description)
          // xar1 = managedConn1.getXAResource()
          // xar1.start(NOFLAGS)
          // I use the conn1 handle
          conn1.close();
          //xar1.end(SUSPEND)
          ConnHandle conn2 = myCF.getConnection(myRequiInfo);
          // a new managed connection managedConn2 is instanciated.
          // xar2 = managedConn2.getXAResource();
          // xar2.start(RESUME)
          // I use conn2 handle
          conn2.close();
          // xar2.end(SUSPEND);
          // my bean returns from the remote invocation
          // the client of the bean asks to commit (using UerTransaction.commit on the
          client side)
          // xar2.end(SUCCESS)
          // xar2.commit(onePhase=true);
          // managedConn2.cleanup();
          And that's all. So, as one can see, managedConn1.cleanup was never called.
          When looking in the weblogic console, I can see that I have one connection
          with 0 handle and one with 1 handle, deemed as still being in a transaction.
          So, the conenction manager apparantly loses a managed connection during the
          transaction. And it's very very bad because after a couple of transactions,
          I'm running out of managed connections (I had set a limit of 10).
          Any one has seen such a weird behavior ? Is this a problem on my side, or
          weblogic's ? Thanks for your help.
          Sylvain
          

Answer 1

          I ran another test. This time I have a bean that makes use of a connector
          once per method invocation. The bean method invoked is "sayHello" and it
          gets a connection to the EIS, perform an operation on it and release it. The
          connector I developed uses XA transactions.
          My test client just calls 3 times myBean.sayHello().
          I can distinguish two cases:
          1) first, the client doesn't do transaction demarcation. In this case, since
          the sayHello method is marked as requiring transaction, the folowing happens
          in the bean:
          // **** first invocation of the bean
          connHandle = myCF.getConnection();
          // managedConn1 is instanciated
          // xar1 = managedConn1.getXAResource()
          // xar1.start(NOFLAGS);
          // managedConn1.getConnection gives a connection handle
          connHandle.doSomeWork();
          connHandle.close()
          // xar1.end(SUCCESS);
          // the bean returns from its invocation
          // xar1.commit(onePhase=true)
          // managedConn1.cleanup()
          // **** second invocation of the bean
          connHandle = myCF.getConnection();
          // managedConnectionFactory.matchManagedConnection is called. It returns the
          managed connection (managedConn1) that is in the passed set
          // xar1 = managedConn1.getXAResource()
          // xar1.start(NOFLAGS);
          // managedConn1.getConnection gives a connection handle
          connHandle.doSomeWork();
          connHandle.close
          // xar1.end(SUCCESS);
          // the bean returns from its invocation
          // xar1.commit(onePhase=true)
          // managedConn1.cleanup()
          // **** third invocation of the bean
          connHandle = myCF.getConnection();
          // managedConnectionFactory.matchManagedConnection is called. It returns the
          managed connection (managedConn1) that is in the passed set
          // xar1 = managedConn1.getXAResource()
          // xar1.start(NOFLAGS);
          // managedConn1.getConnection gives a connection handle
          connHandle.doSomeWork();
          connHandle.close
          // xar1.end(SUCCESS);
          // the bean returns from its invocation
          // xar1.commit(onePhase=true)
          // managedConn1.cleanup()
          2) second case : the client performs transaction demarcation. In that case,
          the connection manager instanciates 3 managed connections, calls start/end
          on each XAResource corresponding to each managed connection, calls commit
          once, but also calls cleanup only once, leaving 2 lost managed connections
          The client looks like this:
          UserTransaction utx = context.lookup("javax/transaction/UserTransaction");
          utx.begin();
          MyBean myBean = ctx.lookup(".......");
          myBean.sayHello();
          myBean.sayHello();
          myBean.sayHello();
          utx.commit();
          on the server the following happens:
          // **** first invocation of the bean
          connHandle = myCF.getConnection();
          // managedConn1 is instanciated
          // xar1 = managedConn1.getXAResource()
          // xar1.start(NOFLAGS);
          // managedConn1.getConnection gives a connection handle
          connHandle.doSomeWork();
          connHandle.close()
          // xar1.end(SUSPEND);
          // the bean returns from its invocation
          // **** second invocation of the bean
          connHandle = myCF.getConnection();
          // managedConn2 is instanciated
          // xar2 = managedConn2.getXAResource()
          // xar1.isSameRM(xar2) is called. returns true
          // xar2.start(RESUME);
          // managedConn2.getConnection gives a connection handle
          connHandle.doSomeWork();
          connHandle.close()
          // xar2.end(SUSPEND);
          // the bean returns from its invocation
          // **** third invocation of the bean
          connHandle = myCF.getConnection();
          // managedConn3 is instanciated
          // xar3 = managedConn3.getXAResource()
          // xar2.isSameRM(xar3) is called. returns true
          // xar3.start(RESUME);
          // managedConn3.getConnection gives a connection handle
          connHandle.doSomeWork();
          connHandle.close()
          // xar3.end(SUSPEND);
          // the bean returns from its invocation
          // the client invokes commit on the UserTransaction
          // xar3.end(SUCCESS);
          // xar3.commit(onephase = true);
          // managedConn3.cleanup();
          And so, managedConn1 and managedConn2 got lost in the way...
          What's more puzzling, it's that when monitoring my connector with the
          console, I can see that there are 3 connections. 2 declared as still having
          one handle used and being in transaction, and one not in transaction and
          with 0 active handle. BUT when monitoring the JTA part of the server, I can
          see that there has been 1 transaction that committed, and no connection is
          "in flight" as the console says. So, on one side the console says 2 managed
          connections are still part of a transaction while on the other it says that
          no transactions are currently in flight.
          Thanks for any kind of help on this very bizarre behavior.
          Sylvain