春季JPA @交易原子

Question

Using Hibernate JPA and Spring @Transactional (with Atomikos JTA implementation) I have the following Entities in my system:

• Order
• Orderline (holds a reference to the order)
• Customer

In a Service class method addOrder annotated with @Transactional I want to perform the following steps, in one transaction (it's one atomic function block).

1. Persist the Order
2. Persist the Orderlines
3. Persist the Customer

At step 1 (persisting the Order) I want JPA to rollback on any Exception .

At step 2 (persisting the Orderlines) I want to ignore any errors during the persisting of an orderline. So if I have 10 orderlines and 1 fails for any reason (constraint violation for example) I want to continue with the others.

At step 3 In case of any Exception I want JPA to rollback the entire transaction, so also everything that was done in step 1 and 2.

Problems I ran into, so far:

• JPA marks the transaction as 'rollback only' in case of an Exception . So everything after (and before) this is rolled back, but I want to ignore the Exception at step 2.
• JPA only knows about the constraint violation after a flush() or commit() is called, which is usually after the @Transactional method is finished. I would need to know it inside my method.
• Tried to split each step in a separate @Transactional method, but since they need to use the same Transaction this doesn't change the previous two issues.

What is the best approach for this?

Update

Should I put all validation in Java and manually check if a record already exists for example?

Answer 1

Put the second part in a try-catch block. For ex: The method body would probably look like this.

save(order);
flush();
for(Orderline line : orderlines) {
    try {
        orderlineService.save(line); 
        flush();   
    } catch(RuntimeException rte) {
        continue;
    }
}
save(customer);

Answer 2

At step 2 (persisting the Orderlines) I want to ignore any errors during the persisting of an orderline. So if I have 10 orderlines and 1 fails for any reason (constraint violation for example) I want to continue with the others.

@Transactional is by default REQUIRED. Each method invocationg joins the current Transaction making all 3 operations atomic.

But in this case you should create a reentrant method using REQUIRES_NEW, indicating a new transaction for persisting each Orderline:

@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void persistMyOrderLine(OrderLine o) throws Exception{}

because failures persisting an orderline should not impact on another, a new transaction must be created for each one. So, aborting the TransactionA-OrderLineA does not impacts on TransactionB-OrderlineB.

The problem is : with your needs, by nature, the operation is not ATOMIC anymore. Because you have a scenario that a failure (orderline) is ignored, the operation is not ATOMIC and will not abort the role process (3 steps).

Maybe you should review these needs.

Answer 3

Is the order necessary? Can Step 2 become Step 3?

If so, put steps 1 & 3 into a single transaction, and each individual persist Orderline into it's own transaction to be run afterwards. Of course, this won't work if you need to rollback if all Orderlines fail to persist...

Another approach may be to create an unmanaged EntityManager for working with your Orderline entities; start transactions, catch exception, and manage commit/rollback on your own for them.

Ideally you'd use a nested transaction, which JPA / JTA doesn't directly support . You can have some semblance by making the outer transaction's commit/rollback dependent on the inner transactions success/failure - or ignore (in your case) the inner transaction.

"Atomicity" tends to be a relative beast in practice - dependent much on the strength of your "transaction isolation" and chosen "locking level" (optimistic or pessimistic w/ variations).

My initial thoughts on this is that if you approached this like a thread-synchronization problem, and maintained some consistency on the order of nesting ('outer' always dealing with X, and 'inner' always dealing with 'Y') - you should be OK because the serialized order in which changes are applied would remain consistent.