Sharing transaction across WebLogic WorkManager threads (using CommonJ)

Question

I have configured Work Managers on my entity beans that I look up via JNDI. The idea behind the change was to multi-thread some of the validation as it can be time consuming, but this requires access to the current transaction.

From my testing, it appears that transactions are not accessible in the worker threads. I would very much like to access the transaction in my worker threads - can I do this?

I was hoping to do something similar to this ExecutionContext where the XID object is passed when work is scheduled, meaning that it inherits the current transaction. Does WebLogic support this?

This is what I have done:

I've added a work manager definition to weblogic-ejb-jar.xml as follows:

  <work-manager>
    <name>wm/EJBWorkManager</name>
    <min-threads-constraint>
      <name>EJBWorkManager_MinThreadCount</name>
      <count>5</count>
    </min-threads-constraint>
  </work-manager>

Added a reference on the bean definition in ejb-jar.xml

  <resource-ref>
    <description>Work Manager allows multi-threading of defined units of work.</description>
    <res-ref-name>wm/EJBWorkManager</res-ref-name>
    <res-type>commonj.work.WorkManager</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>

Then in my code I have looked up the Work Manager and scheduled some work to execute.

weblogic.transaction.Transaction tx = ( weblogic.transaction.Transaction ) weblogic.transaction.TransactionHelper.getTransactionHelper().getTransaction();
log.info( tx != null ? tx.getXid().toString() : "No Transaction" );
try {
  InitialContext initialContext = new InitialContext();
  WorkManager workManager = ( WorkManager ) initialContext.lookup( "java:comp/env/wm/EJBWorkManager" );
  List<WorkItem> workItems = new ArrayList<WorkItem>(); 
  for ( int i = 0; i < 2; i++ ) {
    Work work = new Work() {
      public void run() {
        weblogic.transaction.Transaction tx = ( weblogic.transaction.Transaction ) weblogic.transaction.TransactionHelper.getTransactionHelper().getTransaction();
        log.info( tx != null ? tx.getXid().toString() : "No Transaction" );
      }
      public boolean isDaemon() {
        return false;
      }
      public void release() {
      }
    };
    workItems.add( workManager.schedule( work ) );
  }
  workManager.waitForAll( workItems, WorkManager.INDEFINITE );
} catch ( NamingException e ) {
  throw new RemoteException( "Error", e );
} catch ( IllegalArgumentException e ) {
  throw new RemoteException( "Error", e );
} catch ( InterruptedException e ) {
  throw new RemoteException( "Error", e );
} catch ( WorkException e ) {
  throw new RemoteException( "Error", e );
}

The output I get is as follows which shows that the transaction is not available in the spawned threads. Is it possible to share this transaction into the worker threads? I thought they had done this as part of JCA 1.5 (JSR 112).

16 [[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO com.tracegroup.isys.weblogic.beans.session.SimpleEJB - BEA1-0474BACB4707C088B359
16 [[STANDBY] ExecuteThread: '10' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO com.tracegroup.isys.weblogic.beans.session.SimpleEJB - No Transaction
16 [[STANDBY] ExecuteThread: '10' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO com.tracegroup.isys.weblogic.beans.session.SimpleEJB - No Transaction

Edit: I have tried using weblogic.connector.work.WorkManager & javax.resource.spi.work.WorkManager also, but these failed to get returned when performing the JNDI lookup. These do appear to allow an ExecutionContext to be passed to the work manager, allowing the XID to be given. My initial tests with these classes appeared not to work. Perhaps I have missed something?

Answer 1

Official word from Oracle Support Call:

Not possible/supported. JTA has a single threaded model.

The one case where multiple threads can be involved in a single transaction is where there's a call out to a remote server. The remote server is enlisted as a sub-coordinator. Even then, the overall flow of control is single threaded, so extending this model to a local pool of threads wouldn't buy you anything.