As the best approach, the service layer of the application is the best place to demarcate the transactions. Let's see this in the following code:

    @Service 
    public class TransferServiceImpl implements TransferService{ 
      //... 
      @Transactional 
      public void transfer(Long amount, Long a, Long b){ 
        // atomic unit-of-work 
      } 
      //... 
    } 

As you can see in the preceding code, TransferServiceImpl is our service class at the service layer of the application. This service is the best place to demarcate the transactions for units of work. Spring provides the @Transactional annotation to demarcate the transactions; this annotation can be used at either the class level or the method level of the service classes in the application. Let's look @Transactional at the class level:

    @Service 
    @Transactional 
    public class TransferServiceImpl implements TransferService{ 
      //... 
      public void transfer(Long amount, Account a, Account b){ 
        // atomic unit-of-work 
      } 
      public Long withdraw(Long amount,  Account a){ 
        // atomic unit-of-work 
      } 
      //... 
    } 

If you declare the @Transactional annotation at the class level, all business methods in this service will be transactional methods.

But only using this annotation in the Spring application is not enough. We have to enable the transaction management feature of the Spring Framework by using the @EnableTransactionManagement annotation in the Java configuration file of Spring, or we can use the namespace <tx:annotation-driven/> in the XML configuration file. Let's look the following code, for example:

    @Configuration 
    @EnableTransactionManagement 
    public class InfrastructureConfig { 
    
      //other infrastracture beans definitions 
    
     @Bean 
     public PlatformTransactionManager transactionManager(){ 
         return new DataSourceTransactionManager(dataSource()); 
     } 
   } 

As you can see in the preceding code, InfrastructureConfig is the Java configuration file of the Spring application--here, we define infrastructure-related beans, and one of the transactionManager beans too has been defined here. This configuration class annotated with one more annotation is @EnableTransactionManagement--this annotation defines a Bean Post-Processor in the application, and it proxies @Transactional beans. Now, take a look at the following diagram:

As you see in the preceding diagram, the TransferServiceImpl class is wrapped in a Spring proxy.

But to know what happens exactly with the @Transactional beans in the application, let's see the following steps:

1. The target object is wrapped in a proxy; it uses an Around advice as we have discussed in Chapter 6, Spring Aspect Oriented Programming with Proxy & Decorator Pattern.
2. The Proxy implements the following behavior:

1. Start transaction before entering the business method.

2. Commit at the end of the business method.

3. Roll back if the business method throws a RuntimeException--it is the default behavior of a Spring transaction, but you can override it for checked and custom exceptions also.

3. The transaction context is now bound to the current thread in the application.
4. All steps controlled by the configuration either in XML, Java or Annotations.

Now take a look at the following diagram of a local JDBC configuration with the associated transaction manager:

In the previous diagram, we have defined a local data source using JDBC and a DataSource Transaction Manager.

In the next section, we'll discuss how to implement and demarcate transactions programmatically in the application.