CODEWITHSUNDEEP
springspring-transactions
ams
ams

Reputation: 62722

When to use Spring @Transactional (propagation = Propagation.SUPPORTS)?

According to the Spring javadoc @Transactional(propagation = Propagation.SUPPORTS)

Support a current transaction, execute non-transactionally if none exists. Analogous to EJB transaction attribute of the same name.

It seems that I can just declare methods non transactionaly and be just done with it so my questions are.

Can anyone give a real world example / scenario where SUPPORTS was actually useful?

Upvotes: 33

Views: 31506

Answers (5)

mcoolive
mcoolive

Reputation: 4205

One usage for @Transactional(propagation = Propagation.SUPPORTS) is to override a declaration inherited from an interface, with another propagation value.

Upvotes: 0

Sankozi
Sankozi

Reputation: 578

Using Propagation.SUPPORTS you can trigger setting rollback only flag when exception is thrown. For example in the following code although there is a catch block UnexpectedRollbackException will be thrown when leaving txRequired block.

TransactionTemplate txRequired = new TransactionTemplate(platformTransactionManager);
TransactionTemplate txSupports = new TransactionTemplate(platformTransactionManager);
txRequired.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
txSupports.setPropagationBehavior(TransactionDefinition.PROPAGATION_SUPPORTS);

//prints 'Exception handled' and then throws UnexpectedRollbackException
txRequired.executeWithoutResult(tx -> {
    try {
        txSupports.executeWithoutResult(tx2 -> {
            throw new RuntimeException();
        });
    } catch (Exception ex) {
        System.out.println("Exception handled");
    }
});

Code below will obviously not throw any exception. The only difference is lack of PROPAGATION_SUPPORTS block.

txRequired.executeWithoutResult((tx) -> {
    try {
        throw new RuntimeException();
    } catch (Exception ex) {
        System.out.println("Exception handled");
    }
});

Upvotes: 0

Grigory Kislin
Grigory Kislin

Reputation: 18020

According this issues Improve performance with Propagation.SUPPORTS for readOnly operation you should not set read-only transaction with Propagation.SUPPORTS:

It's by no means clear that the change would actually improve performance. There's multiple aspects in this. First of them is that the linked article is dated and incredibly flawed as it aggressively simplifies things. I can go into details if you want but I'll leave it at that for now. There are a lot of things playing into execution performance here. Without a transaction in progress neither the readOnly flag is propagated to the JDBC driver (which would cause optimizations for a lot of databases not being applied) nor would you apply the optimizations in Spring's JPA resource management code like explicitly turning off flushing, which - if applied - can dramatically improve performance in case you read a lot of data.

Upvotes: 0

dimitrisli
dimitrisli

Reputation: 21401

It makes a good pair along with the readOnly=true Transactional flag on a select operation especially when ORM is used:

@Transactional(readOnly = true, propagation=Propagation.SUPPORTS)
public Pojo findPojo(long pojoId) throws Exception {
   return em.find(Pojo.class, pojoId);
}

In this case you make sure not to pay to price of creating a new transaction if there isn't one already just for performing a select operation.

Although if you have been in that thought process already you might even consider ditch the Transactional aspect all together:

public Pojo findPojo(long pojoId) throws Exception {
   return em.find(Pojo.class, pojoId);
}

Upvotes: 6

Affe
Affe

Reputation: 47994

Easiest example I can think of would be a method that sends some content to a JMS server. If you are in the context of a transaction, you want the message to be coupled to the transaction scope. But if there isn't already a transaction running, why bother calling the transaction server also and starting one just to do a one-off message?

Remember these can be declared on an API as well as an implementation. So even if there isn't much difference for your use case between putting it there and putting nothing there, it still adds value for an API author to specify what operations are able to be included in a transaction, as opposed to operations that perhaps call an external system that does not participate in transactions.

This is of course in a JTA context. The feature doesn't really have much practical use in a system where transactions are limited to resource-local physical database transactions.

Upvotes: 8

Related Questions