@Transactional call from failures
Sometimes configuration annotations @Transactional, but it fails to note here some of the details, in order to avoid falling into the trap.
Notes @Transaction underlying implementation is Spring AOP technology, and Spring AOP technology uses dynamic proxy. This means that for a static (static) methods and non-public methods, notes @Transactional is failure. There is also a more intimate, but also in the course extremely easy to make mistakes - from calls.
The so-called self-called, is a method of a class to call another method of the process itself.
The emergence of the root cause of the problem is the realization of the principle of AOP. Since the implementation of the principle is @Transactional AOP, but the principle is that the dynamic AOP proxy, which calls itself the process, there is no proxy object to call, so it will not produce AOP to set the parameters for our @Transactional configuration, so there is a problem since the failure of the call notes.
To overcome this problem, one can use two service classes, Spring IoC container generates a proxy object RoleService for you, so that you can use AOP, and will not be a problem since the call. On the other hand, you can also get a proxy object Service directly from the container, get RoleService proxy object from the IoC container. But there is a downside, it is to obtain the proxy object from a container suspected invasive methods, the classes you need to rely on the Spring IoC container
Analysis of typical errors usage
Transaction data is the core of enterprise applications concern is the developer of the most fallible problem, so the author here to explain the use of some bad habits, they pay attention to avoid mistakes and lose some performance.
Misuse Service
Internet often using Model - View - Controller (Model View Controller, MVC) development environment to build, so using Service is very common in the Controller.
In the Controller every service call with the transaction will create a database transaction. If multiple calls, not in the same transaction, which can cause problems not commit and rollback inconsistency at the same time. Each Java EE developers should pay attention to these issues, in order to avoid unnecessary mistakes.
Too long occupation Affairs
In the production system, database transaction resource is one of the most valuable resources, then use the database transaction, to promptly release a database transaction. In other words, we should use as much as possible the database transaction resources to complete the necessary work, but some work is required to file, external connections and other operations, and these operations tend to take a long time for this, if the developers do not pay attention details, the problem is very prone to system downtime.
Some communication between the system and some of which may take a long time of operation, should pay attention to this issue, on the external controller layer processing and other transactions to avoid prolonged occupation of a database transaction, resulting in poor system performance.
Catch an exception error
service with a transaction, you want to roll back abnormal should throw an exception, rather than capture