The previous chapter on Spring DAO gave you good hands-on practice on how Spring handles JDBC API with loose coupling. However, we neither talked about JDBC transactions, nor about how Spring handles transactions. If you have already handled transactions, you will know the steps for it; moreover, you will be well aware of the steps that are repetitive, and spread all over the code. On one hand, we recommend using Spring to stop duplication of code, and on the other hand, we write such code. Java insists on writing modules that are highly cohesive. However, writing transaction management in our code won't allow us to write cohesive modules. Also, the transaction is not the motive of writing the code. It just provides support so that the business logic of the application does not carry out any undesired effect. We haven't discussed how to handle such supportive functionalities or the main motive of application development. Transaction management is one of the supportive functionalities. What are the other supportive functionalities used while developing an application? This chapter will help us in writing highly cohesive modules without repetition of code to handle such supportive functionalities. In this chapter, we will cover the following topics:

• Defining cross-cutting technologies
• Role of cross-cutting technologies in application development
• AOP and its important role in handling cross-cutting technologies
• Aspects, Advices, and PointCut in AOP

A software is an application that provides a reliable solution to a client's problem. Though we say reliable, there is always a chance of getting some runtime problems. So, along with development, maintenance of the software is also equally important. Whenever a problem occurs in an application, the client gets back to the developers for the solution. Unless and until the client is not able to state the accurate reason for the problem, the developers are helpless. They have to recreate the same situation in order to prevent its next occurrence. In enterprise application, due to a large number of modules, reproducing the same problem becomes complex. It will be great to have someone who keeps track of what the user is doing. The trace of this tracker helps the developers know why and what went wrong, or even use the trace so that they can recreate it easily. Yes, I am talking about the logging mechanism.

Let's take another very common situation of Railway ticket reservation. At the time of ticket reservation, we select the available seat from the chart, and proceed for money transfer. Sometimes, the money gets transferred successfully and the ticket gets booked as well. However, unfortunately, sometimes, the time taken for the money transaction, delay in form filling, or some server-side issues may cause problems for transferring money without booking the ticket. The money gets deducted without issuing of the ticket. The customer will be unhappy, and tense for the refund. Such situations need to be handled carefully with the help of transaction management so that if the ticket is not issued, the money should get deposited back into the customer's account. Doing it manually will be a tedious task; however, transaction management handles it elegantly. We all know how important transaction management and logging are for an application. However, these are not the core concerns. Oops! That makes me wonder, what are core concerns and cross-cutting concerns? Let's discuss them first before moving ahead.