The article directories

      • “@Tranactional ensures consistent transactions
      • The return and throw

“@Tranactional ensures consistent transactions

When writing DAO layer code, you might write updates or inserts to multiple tables in a method, and to ensure consistent local transactions, you might use the @Tranactional annotation, which says: If a method annotated with this annotation throws an exception, all logic that the method has executed is rolled back to ensure the consistency of the local transaction. Methods annotated with the @Transactional annotation either do not execute or all execute normally.

It’s important to note that @Tranactional rolls back only Runtime exceptions and not compile-time exceptions. Even with run-time exceptions, there are probably two types of exceptions: an exception thrown by SQL itself (insert primary key conflict or unique index conflict), and an exception thrown by a programmer (update returns 0 rows).

In curd, select null if the select condition is not found, and return the specified record if it is found. Update if the specified where condition is not found, the row will not be updated, but no exception will be raised. The insert statement will throw a runtime exception if the primary key or unique index conflicts and cannot be inserted, but will not throw an exception if the insert is normal. Delete usually does not use physical delete, is set a field, do a pseudo-delete update.

Select does not have an exception and does not throw an exception; “Inserts are tossed when they have exceptions, and @Tranactional actional rollback”; However, if update is not updated to the point where it does not throw an exception, @Transactional will not catch it, defeating the purpose of rollback. This is something programmers need to take into account.

If it is a Throw new MyBusinessException (select could not be found, or update could not be thrown) or an internal runtime exception that is not handled by the method’s catch, the local transaction rollback is triggered and wrapped as an error return value by the global interceptor. Send it to the front end.

It is important to note that the MyBusinessException here must directly or indirectly inherit from RuntimeException, guaranteed to be a RuntimeException.

Example 1: Throw new MyBusinessException (select not thrown) to ensure that subsequent updates will not be executed, thus ensuring transaction consistency.

Person person = personDao.getPersonByAge(age);
if(person==null)
   throw new  MyBusinessException();
updatePersonByAge(age);
Copy the code

Throw new MyBusinessException(update thrown) to ensure transaction consistency

Integer row  = updatePersonByAge(age);
if (row < 1)
    throw new  MyBusinessException();  
Copy the code

Example 2:

insertPerson(person);
Copy the code

If insertPerson fails, an exception is thrown internally by THE SQL, which is captured by @Tranactional, rolled back locally, and then global interceptors assemble error messages to the front end to ensure transaction consistency.

Have seen someone write code like this:

if(! insertPerson(person)){return resultMap;
}
Copy the code

Not necessary, if insertPerson is healthy, return true, return resultMap is not executed; If insertPerson has an internal error, the SQL will throw an exception internally, which is “caught” by @Tranactional, and rolled back locally, then global interceptors assembly error messages to the front end to ensure transaction consistency, and return resultMap is not executed.

Therefore, it is meaningless to judge the return result of insertPerson, and the return resultMap will never be executed;

The return and throw

In general, use throw instead of return.

If a return does not have an update before it, use throw. If a return does have an update before it, use throw. If an error occurs, use throw to rollback the update before it.

Insert is not a problem in the common curD business. The @Transactional annotation can be rolled back if primary key duplication causes problems. Other INSERT problems can also be rolled back to ensure transaction consistency.

Update:

Select * from (select * from (select * from (select * from (select * from (select * from (select * from (select * from (select * from)))))); There is no update in front, so there is no need to roll back.

(2) If the update is not the first update, you can only use the select for update + throw + update (or update + throw) exception. Ensure that the previous update is rolled back.

Return int (int); throw (int); return int (int);