Very important notes about Spring @Transnational

Sprint @Transnational is being ignored in the following cases:

1. when the caller method is calling the @Transaction annotated method from the same class

2. When the Annotated method is not public

@Transnational by default don't rollback for Checked Exceptions


class A{
     void caller(){
            doInTransactionMethod(); // @Transnational is ignored
     }

    @Transnational // by default rollback for RuntimeExceptions
    public <return type> doInTransactionMethod(<params>){ // should be public as well
    }
}

The problem is, I keep forgetting about the above 3 simple rules, So I tried to writing down here to try not to forget about it

 Also, here is a tweet that talks about public default limitation: https://twitter.com/mohewedy/status/1099781513888100352

"By default, only public methods can be made transactional." #springframework #AnnotationTransactionAttributeSource #EanableTransactionManagement #BeanFactoryTransactionAttributeSourceAdvisor

I hope I never forgot about you again and again and again 😅😅😅

— Muhammad Hewedy (@mohewedy) February 24, 2019

Using spwrap inside spring transactions

spwrap is a little library that simplify calls to database stored procedures in java.

Read this introduction to talk an idea about spwrap before continue reading this post.

We have talked before about how to use spwrap in spring boot application.

Today we will talk about a new feature just release in version 0.0.18, which is spwrap now can participate in spring transactions.

spwrap itself doesn't allow spanning transaction across DAO method calls. but as part of 0.0.18, it will participate in spring Transactions if spwrap is used inside spring and there's an active transaction.

Suppose we have a spring project with Datasource transaction manager is enabled.

And we have  SupplierDAO which is a spwrap DAO defined like this:

public interface SupplierDAO {

    @StoredProc("insert_new_supplier")
    void insertSupplier(@Param(VARCHAR) String name);
}

And we have a domain object supplier and its spring-data-jpa repository

@Entity
public class Supplier {

    @Id    @GeneratedValue(strategy = AUTO)
    private Long id;

    @Column(unique = true)
    private String name;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}
// -- repository
public interface SupplierRepo extends JpaRepository<Supplier, Long> {
}

And here's the service class:

@Service
public class SupplierService {

    private SupplierDAO supplierDAO;
    private SupplierRepo supplierRepo;

    public SupplierService(SupplierDAO supplierDAO, SupplierRepo supplierRepo) {
        this.supplierDAO = supplierDAO;
        this.supplierRepo = supplierRepo;
    }

    @Transactional
    public void add2Suppliers(){
        final String supplierName = "Abdullah";

        supplierDAO.insertSupplier(supplierName);   // << will rolled-back

        Supplier s2 = new Supplier();
        s2.setName(supplierName);
        supplierRepo.save(s2);      // throws exception
    }

    public List<Supplier> listSuppliers(){
        return supplierRepo.findAll();
    }
}

Now because the supplierDAO.insertSupplier(supplierName) insert supplier with name "Abdullah", and supplierRepo.save(s2) insert supplier with the same name, then spring frameowkr will throw DataAccessException subclass and rollback the entire transaction.

Which meaning the stored procedure that is executed as a result of calling supplierDAO.insertSupplier(supplierName) will be rollbacked as well. Again, this is a new feature as part of spwrap 0.0.18. 

You can see the full example at github: https://github.com/mhewedy/spwrap-examples/tree/master/spring-boot-transactions-mysql Don't forget, if you like the spwrap library, don't forget to like the project page at github.

Using @Transactional to trigger rollback on runtime exceptions

In the last post, I've discussed some thoughts about trying to understand spring transactions.

Although not complete (and it appears it has issues as well). but today's topic is so compact and clear.

Spring follow's EJB transaction on that, it rollback on RuntimeException.

Suppose we have the following method:

@Transactionl
public void myServiceMethod(){
    updateDatabase();
    callSomeQueueOrWebService();
}

so, if the the second method call fails with RuntimeException, then the whole transaction will rollback causing the first method to rolled back.

But if you don't annotate the method with @Transactional, then both method calls (updateDatabase() and callSomeQueueOrWebService() ) will run independently and one might success however the other case fail.

Code:

Service Layer:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

private String fName = "Mohammad", lName = "Hewedy"; @Transactional public void updateDbAndCallWSTrans() { userRepo.save(User.of(null, fName, lName)); callWsThatThrowsException(); } public void updateDbAndCallWSNoTrans() { userRepo.save(User.of(null, fName, lName)); callWsThatThrowsException(); } public Stream<User> getDbUpdate() { return userRepo.findByFNameAndLName(fName, lName); } private void callWsThatThrowsException() { // automatic rollback for runtime exceptions only! throw new RuntimeException("EXCEPTION from WS"); }

The controller layer:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

@RequestMapping("/tx/user") public ResponseEntity<?> getDbUpdate() { return ResponseEntity.ok(userService.getDbUpdate().toArray(User[]::new)); } @RequestMapping("/tx/add-w") public ResponseEntity<?> updateDbAndCallWSTrans() { userService.updateDbAndCallWSTrans(); return ResponseEntity.ok().build(); } @RequestMapping("/tx/add-wo") public ResponseEntity<?> updateDbAndCallWSNoTrans() { userService.updateDbAndCallWSNoTrans(); return ResponseEntity.ok().build(); }

Note, the call to /tx/add-w will not insert any data into the database, and calls to /tx/user will return empty.

However, the call to /tx/add-wo, will insert the user object into the database, and call to /tx/user will return the inserted users object.

My thoughts about Spring Transactions

I've some thoughts about spring (and spring-boot) transactions I want to list somewhere, and I think here's a nice place.

Preface

Spring do transaction management through PlatformTransactionManager interface.

This interface has implementation for different kinds of datasources, for example for DataSourceTransactionManager, HibernateTransactionManager, HibernateTransactionManager, JmsTransactionManager, JpaTransactionManager and others.

In a typical JPA application, the JpaTransactionManager is being used.

In SpringBoot, All the JpaRepository are annotated with @Transactional annotation.

This annotation used by spring to do the Declarative transaction management.

So, the Developer uses this annotation to control many things, included the transaction propagation (REQUIRED, REQUIRED_NEW, SUPPORTED, etc), the isolation level (READ_COMMITED, READ_UNCOMMITED, etc.) and the rollback exception, timeout and more.

And behind the since, the platform-specific transaction manager along with the databasource do the actual work.

@Transactionl

So, many people says, use the @Transactional annotation on the service layer, you might need to use it on DAO (now called Repository) layer, but do not use it on the controller layer.

In spring boot, as I said, all the out-of-the-box methods that you get by implementing the JpaRepository are already have the @Transactional annotation (see SimpleJpaRepository). And I think hence the @Transactional on the implementation class itself, then all your repo methods might have the annotation as well.

But this is not the problem, the problem in the Service layer.

@Transactionl in the Service layer

What if I didn't put the Transactional annotation on my service methods?
Then your method will not run in a transaction, so If you have a service method that do the following

public void serviceMethod(){
     insert1();
     insert2();
}

insert1() might succeed and inserts data into the database, while insert2() fails.

In this case you should put the @Transactional annotation on your service method if you want to have all or none.

@Transactionl and noRollbackFor

The rollback is controlled by RuleBasedTransactionAttribute
see http://docs.spring.io/autorepo/docs/spring/current/spring-framework-reference/html/transaction.html#transaction-declarative-rolling-back

In its default configuration, the Spring Framework’s transaction infrastructure code only marks a transaction for rollback in the case of runtime, unchecked exceptions; that is, when the thrown exception is an instance or subclass of RuntimeException. ( Errors will also - by default - result in a rollback). Checked exceptions that are thrown from a transactional method do not result in rollback in the default configuration.

Also,

When the Spring Framework’s transaction infrastructure catches an exception and is consults configured rollback rules to determine whether to mark the transaction for rollback, the strongest matching rule wins 

For rollbackFor and noRollbackFor;

I think spring take the exception thrown and check to see how it is close (in inheritance hierarchy) to the declared exceptions (in rollbackFor and noRollbackFor). If it is closer to an exception declared in rollbackFor more than one declared in noRollbackFor, then the transaction will be rollbacked. and vice versa.

ex:
We have this heirarcy:
class Exception1{}
class Exception2 extends 1{}
class Exception3 extends 2{}

@Transactional(rollbackFor=Exception1.class, noRollbackFor=Exception2 .class)
public void myMethod(){
        throw new Exception3 ();
}

In this case, the transaction will NOT be rollbacked, because the thrown exception (Exception3) is closest to exception in noRollbackFor (Exception2) than the exception in rollbackFor (Exception1)

And if the closest exception declared in rollbackFor, the spring will rollback the tx, otherwise it will not rollback it:

in RuleBasedTransactionAttribute: return !(winner instanceof NoRollbackRuleAttribute);

@Transactionl and lazy evaluation

lazy evaluation is important aspect in web development, it facilities things, lazy evaluation includes not only evaluate lazy associations in the Controller layer, but also evaluation lazy Streams. (Thanks to OpenEntityManagerInViewFilter).

But if you choose to annotate your service method with @Transactional, lazy transaction data will not be available in the Controller layer (and exceptions will be thrown as well).

Here's an example issue.

So, some people says, at service layer get all the data you want and then send it to the controller layer as eager so you don't need the service layer's transaction anymore.

I think for finder services, you might not need to have the @Transactional annotation, so you can make use of the OpenEntityManagerInViewFilter (which is provided by springboot by default) and be able to  enjoy your laziness in the controller layer.(It seems the "Open EntityManager in View" has nothing to do here, it only allow the transaction manager to use an EntityManager created by him. because if you have @Transactional and have this pattern on, the exception will continue to throw if you try to access lazy data out of the transactions.

But in case of services that updates the database, you do need to use the @Transactional annotation to control the things not to go messy!

@Transactionl on controller and service layer

If you have a finder method that returns a lazy object (java 8 stream or lazy association as in hibernate), the if you have the @Transactional annotation on the service layer, then the lazy parts of  object will not be available to the controller layer.

However, if you put the @Transactionl annotation on the controller layer as well (which many people don't recommend) then the lazy part will be available to the controller layer unless you make the transaction propagation on the service layer as REQUIRED_NEW, in this case the service layer will suspend the controller's transaction and start/end it's own transaction and will send back the object to the controller out of its transaction and the problem will still exists.

Conclusion

For now, I'll  - mostly, because some times I do not need it - use @Transactionl on Service methods that do update (Add/update/delete) the database.

However for finder service methods (that query the database), it is better to have the @Transational(readOnly=true) on it, but since I didn't understand - till now- much more, I'll choose not to use this annotation so I can deal with my laziness objects in the controller layer)

Interesting classes to see the source code of:
1. TransactionInterceptor: class source code to see what is happening internally. (very interesting)
2. TransactionAspectSupport:
  a. method: invokeWithinTransaction
  b. method: completeTransactionAfterThrowing (it shows
3. AbstractPlateformTransactoinManager
 a. method: commit (it shows the rollback if done if "setRollbackOnly" method is being called

The post above is based on my thoughts and is might not be valid.

About Batabase Transactions

DB Transactions has 4 attributes, which is expressed as ACID, where:

A -> Atomicity, means transaction run as an atomic single unit of work, either all is successes and committed or all rollbacked in case of failure.

C -> Consistency, means the transactions should leave the DB data in consistent state, regardless of its success or fail. so, this attribute is ensured using the first attribute.

I -> Isolation, means the user transaction should run in isolation from other users transaction, and no one should affected by others during the single transaction. also this ensures DB consistency.

D -> Durable, means the transaction should be written permanent to the DB after the transaction committed, even if the system crashes afterwards.

When two ore more transactions are operate concurrently on the same data, the following errors might happen:

1. The first transaction write some data to the DB but still the transaction not committed, a second transaction come and read the modified data, then the first transaction rolled-back.
   This called "Dirty reads", and can prevented by applying the "Isolation" attribute, so every transaction should be isolated from other transactions in terms on data modifications.
   
   
2. The first transaction read some data, then a second transaction come and modify that data and then commit, so the data written to the database. meanwhile the first transaction is still running and when come to read the same data again, it find it changed.
   This called "Non repeatable reads" which means multiple reads by some transaction to the same data is differ. and this can prevented by having some row-level locks on the database, so once a transaction start reading/modifying some data no other transaction cannot use until this transaction ends.
   
   
3. The first transaction read some rows using a certain where condition, then a second transaction come and insert a new row that reside in the where condition area and then committed. When the first transaction come and re-query the first select with that certain where condition, it finds the rows number changed.
   This called "Phantom reads" and this cab be prevented by applying table-level lock whenever a transaction come and start reading/modifying some data in a table, the transaction acquire full-table lock.
   

This leads to talk about Isolation levels, which are (from less control to more control, and more control means low performance):

• Read Uncommitted
  Read dirty data, data before being committed by other transactions, leads to all there "Dirty reads", "Non repeatable reads" and "Phantom reads"
• Read Committed
  Read only committed data, lead to only "Non repeatable reads" and "phantom reads".
• Repeatable Read (lock data)
  Transaction acquire lock on the data being read (either cell-level or row-level locks), so nobody can change the data until transaction commit or rollback. but still "Phantom reads" can happen.
• Serializable (lock table)
  Table-level lock. Nobody can touch the whole table until the transaction committed or rolled-back. no isolation violations can happen.

Read more here:
http://en.wikipedia.org/wiki/ACID 
http://en.wikipedia.org/wiki/Isolation_(database_systems)


Source (with my modifications) Spring in action 3rd ed. ch 06