Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop EJB applications > Assembling applications that use the Java Persistence API > Use JPA access intent

Set a TaskName using TaskNameAccessor API

Using the TaskNameAccessor API to set Java Persistence API (JPA) TaskName at runtime.

In the EJB container, a task name is automatically set by default upon a transaction begins. This action is performed when a component or business method is invoked in a CMT session bean or when an application invoke the sessionContext.getTransaction().begin() in a BMT session bean. This TaskName consists of a concatenation of the fully package qualified session bean type, a dot character and the method name. For example: com.acme.MyCmtSessionBean.methodABC.

If using JPA in the context of the web container, an application must use the TaskNameAccessor API to set the TaskName in the current thread of execution. Once a TaskName is set on a transaction context, application must not set the TaskName again in the same transaction. This will avoid problems with on the JDBC connection for different database access.

This example contains the TaskNameAccessor API definition

package com.ibm.websphere.persistence;

public abstract class TaskNameAccessor {

 /**
  * Returns the current task name attached in the current thread context.
  * @return current task name or null if none is found.
  */
 public static String getTaskName ();

 /**
  * Add a user-defined JPA access intent task name to the current thread
  * context.
  *
  * @param taskName
  * @return false if an existing task has already attached in the current
  *         thread or Transaction Synchronization Registry (TSR) is not   *         available (i.e. in JSE environment).
  */
 public static boolean setTaskName(String taskName);

}

This code example shows how to set a TaskName using TaskNameAccessor.

package my.company;

@Remote
class Ejb1 {
    // assumer no tx from the caller
    @TransactionAttribute(Requires)
    public void caller_Method1() {

        // an implicit new transaction begins
        // TaskName "my.company.Ejb1.caller_Method1" set on TSR

        ejb1.callee_Method?();
    }

    @TransactionAttribute(RequiredNew)
    public void callee_Method2() {

        // an implicit new transaction begins i.e. TxRequiredNew.
        // TaskName "my.company.Ejb1.callee_Method2" set on TSR
    }

    @TransactionAttribute(Requires)
    public void callee_Method3() {

        // In caller's transaction, hence TaskName remains
        //     "my.company.Ejb1.caller_Method1"
    }

    @TransactionAttribute(NotSupported)
    public void callee_LocalTx () {

        // Unspecified transaction, a new local transaction implicitly started.
        // TaskName "my.company.Ejb1.callee_LocalTx" set on TSR
    }

}

In the above example, an application must be aware of transaction boundary will be subtly changed if Ejb1 uses local interface (@Local). For example, when caller_Method1() calls callee_Method3 or callee_LocalTx, this will be treated as a Java method call. No EJB transaction semantics are honored.

What to do next

Once we have completed this step, continue on with the topic Specify TaskName in a JPA persistence unit.
Use JPA access intent
Specify TaskName in a JPA persistence unit

+

Search Tips   |   Advanced Search