Hi,

I guess that UserTransaction should be injected or added as JNDI resource via look-up.

Have you read

• Getting Started Developing Applications Guide
• Chapter 11. Java Transaction API (JTA) - Red Hat Customer Portal

Thanks,

Vlad

Hi vata2999 ,

it depends on what you want to achieve. Do the two methods (starttx and the account) run on two different JVMs? Do I understand correctly you want to start a JTA transaction on one JVM (let's say a microservice) and you want the other JVM would join the same transaction? The JTA transactions are associated with one thread in one JVM. If you want to get multiple JVMs to run with one transaction you need to propagate context over the remote call. In this case you expect the transaction context is propagated over HTTP REST calls. Narayana provides for the propagation the subproject REST-AT (atomic transactions for REST) and you need to configure it to your project for propagation to start working. Please take a look at the Narayana quickstart quickstart/rts/at at master · jbosstm/quickstart · GitHub for this purpose.

It's not totally clear to me if you are wanting to use our REST-AT coordinator. If so then you might like to look at quickstart/rts/at/jta-service at master · jbosstm/quickstart · GitHub (look at the src/main and src/test for the demarcation)

However if you just wanting to somehow manage the transaction yourself from a REST resource you would need to handle the suspend/resume yourself perhaps in a filter maybe keyed on some ID for a hashmap you could require your clients to pass you back.

As far as you are using the RestTemplate to invoke the remote REST services and I think you have to propagate the transaction context by some interceptors.

Hmm...
Are you using distributed JTA transactions across multiple XA resources?

Thanks for the details vata2999. If you are not going to use the REST-AT integration then you must take care to asssociate and diassociate the transaction with the thread yourself and note that the payment and account services will either need to be in the same JVM or use a distributed transaction protocol like JTS.

If the payment and account services can be in the same JVM you need something like:

@GetMapping("/starttx")  
public byte[] starttx() throws NotSupportedException, SystemException  
{  
    TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();  
    transactionManager.begin();  
    Transaction transaction = transactionManager.suspend();
    // stash this transaction some place related to a globally unique ID, you could use the Narayana UID
    byte[] bytes = ((com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple)transaction).get_uid().getBytes();
    transactions.put(bytes, transaction);
    return bytes;
}  

@GetMapping("/createAccount")  
public String account(byte[] transactionUID) throws SystemException  
{  
    Transaction transaction = transactions.get(transactionUID);
    tm.resume(transaction);
    em.persist(new AccountEntity("acc1"));  
    return "created account";  
}

@GetMapping("/committx")
public byte[] committx(byte[] transactionUID) {
    Transaction transaction = transactions.get(transactionUID);
    tm.resume(transaction);
    transaction.commit();
}

Hi vata2999 ,

if you call the `transactionManager.begin()` a new transaction is tried to be bound to the current thread (it would be the ThreadLocal variable). If you want to start the transaction you can check the state TransactionManager (Java(TM) EE 8 Specification APIs)  and based on that to decide to start the new transaction with `begin()` or just use the already existing one (TransactionManager (Java(TM) EE 8 Specification APIs) ).

On the reaper. Reaper manages transaction timeout. If the timeout elapses the reaper ensures the transaction is rolled-back. You can define the timeout of transaction with API call - TransactionManager (Java(TM) EE 8 Specification APIs) (you need to do so before the transaction starts aka. before you call `begin()`), you can define default timeout for started transactions by narayana configuration call (`arjPropertyManager.getCoordinatorEnvironmentBean().setDefaultTimeout(...)`). But the Narayana configuration should be set up rather by the descriptor. You can find more details on configuration of narayana in the documentation Narayana Project Documentation  or in this section of the blog post Narayana team blog: Narayana periodic recovery of XA transactions .

Sorry, I missed a tm.suspend in the account method.

public String account(byte[] transactionUID) throws SystemException    
{    
    Transaction transaction = transactions.get(transactionUID);  
    tm.resume(transaction);  
    em.persist(new AccountEntity("acc1"));    
    tm.suspend(); // no need to cache as it will already be in the transactions map from starttx
    return "created account";    
} 

I see Ondra has given some good background on how to setTransactionTimeout.