Transaction Processing hierarchy

I have been thinking about a transaction processing level problem recently. When we are working on J2EE applications, we are used to dividing the applications into three logical layers: The Web layer, the business layer, and the persistent layer. What is more classic is that the persistent layer generally uses the DAO design method. When dealing with database-related transactions, many people are used to processing transactions.CodeWritten on the DaO layer, that is, the persistence layer. In this way, there is no problem in writing a simple database access. Once the implementation is more complex and the involved business processing is more complicated, this method of processing transactions in Dao is a little powerless.

For example, in my dbdao interface, there are two methods: updatea and updateb. In these two methods, we assume that several tables are updated simultaneously (this is common ), this will involve transaction processing. In updatea, we use transactions for processing. In updateb, we also thank the transaction processing statements. Now the problem arises. If a business processing requirement is met, if the updatea is successful, the updateb will be updated. If the updatea fails, rollback is required. In this case, after the business layer calls the updatea for submission, but updateb failed, so there was no way to roll back the method. Of course, we can add two methods without transaction processing in Dao to call, but think about it carefully. Is this suitable ?????

However, you can also write some business implementations into Dao, which can also be processed. However, the business layer and persistence layer are obviously ambiguous and lose the significance of layering.

Therefore, we want to put the transaction processing in the business. The reason is obvious: Transaction processing is the need for business processing and should change with the changes in the business. transactions are not related to the underlying persistence. That is to say, the DaO layer should not have the transaction processing code at all. However, if we put the Database Transaction Processing code behind the business layer, it would seem a bit bad smell. Therefore, we can use the AOP framework, such as spring, to separate transaction processing and control transactions at the business layer. Because the DaO layer receives tasks for transaction processing, any business method can be called with confidence. You only need to add transactions to the business method when a transaction is required.