Warum sollten wir keinen Spring MVC Controller @Transactional machen?

TLDR: dies ist, da nur die service-layer in der Anwendung die Logik, die nötig ist, um zu identifizieren, den Umfang der Datenbank/business-Transaktion. Der controller und Persistenzschicht von design können nicht/sollte nicht wissen, den Umfang einer Transaktion.

Den controller vorgenommen werden können @Transactionalaber in der Tat, es ist eine gemeinsame Empfehlung, nur die service-Ebene Transaktions - (die Persistenzschicht sollte nicht transaktionalen).

Der Grund dafür ist nicht die technische Machbarkeit, sondern die Trennung von Bedenken. Der controller Verantwortung ist, um die parameter fordert, und rufen Sie dann eine oder mehrere service-Methoden und kombinieren der Ergebnisse in eine Antwort, die dann zurück an den client gesendet.

Also der controller hat eine Funktion als Koordinator der Anfrage Ausführung und Transformator der domain-Daten in ein format, das der client nutzen kann, wie DTOs.

Die Geschäftslogik befindet sich auf dem service-layer und die Persistenzschicht nur abrufen /speichern von Daten hin und her aus der Datenbank.

Rahmen einer Datenbank-Transaktion ist wirklich ein business-Konzept, so viel wie ein technisches Konzept: in ein Konto übertragen ein Konto wird nur belastet, wenn der andere gutgeschrieben usw., also nur die service-Schicht enthält die Geschäftslogik kann wirklich wissen, den Umfang einer bank account transfer transaction.

Persistence-layer kann nicht wissen, was die Transaktion ist es, nehmen Sie zum Beispiel eine Methode customerDao.saveAddress. Sollte es so laufen, in einem eigenen separaten Transaktion immer? es gibt keine Möglichkeit zu wissen, es kommt auf die business Logik aufgerufen wird. Manchmal ist es sollte laufen auf einer separaten Transaktion, manchmal nur speichern die Daten, wenn der saveCustomer auch gearbeitet, etc.

Das gleiche gilt für die Steuerung: sollte saveCustomer und saveErrorMessages gehen Sie in der gleichen Transaktion? Möchten Sie vielleicht sparen sich die Kunden und wenn das fehlschlägt, dann versuchen zu speichern, Fehlermeldungen und Rückgabe einer Fehlermeldung an den client, anstatt zu Rollen zurück alles, einschließlich der Fehlermeldungen, die Sie retten wollte auf die Datenbank.

In nicht-Transaktions-Controller, Methoden der Rückkehr aus der service-Ebene zurück detached Entitäten, da die Sitzung geschlossen. Das ist normal, die Lösung ist entweder OpenSessionInViewoder Abfragen, die eifrig die Ergebnisse abrufen der controller kennt, die es braucht.

Having said that, es ist nicht ein Verbrechen zu machen, die Transaktions-Controller, es ist nur nicht die am häufigsten verwendete Praxis.

InformationsquelleAutor der Antwort Angular University

Manchmal möchten Sie ein Rollback einer Transaktion, wenn eine Ausnahme geworfen wird, aber zur gleichen Zeit, die Sie behandeln möchten der Ausnahme, erstellen Sie eine richtige Antwort in der Steuerung.

Wenn Sie @Transactional auf der controller-Methode die einzige Möglichkeit zur Durchsetzung der rollback zu werfen die Transaktion von der controller-Methode, aber dann können Sie nicht zurück eine normale Reaktion-Objekt.

Update: Ein rollback kann auch erreicht werden, programmgesteuert, wie in Rodério Antwort.

Eine bessere Lösung ist es, Ihre service-Methode, Transaktions-und dann Griff eine mögliche Ausnahme in der controller-Methoden.

Das folgende Beispiel zeigt eine user-service mit einem createUser Methode, dass die Methode verantwortlich ist, den Benutzer zu erstellen und senden Sie eine E-Mail an den Benutzer. Wenn das versenden der mail schlägt fehl, wir wollen ein rollback für die Erstellung des Benutzers:

@Service
public class UserService {

    @Transactional
    public User createUser(Dto userDetails) {

        //1. create user and persist to DB

        //2. submit a confirmation mail
        //   -> might cause exception if mail server has an error

        //return the user
    }
}

Dann in deinem controller-Sie können wickeln Sie den Aufruf createUser in einem try/catch, und erstellen Sie eine richtige Antwort für den Benutzer:

@Controller
public class UserController {

    @RequestMapping
    public UserResultDto createUser (UserDto userDto) {

        UserResultDto result = new UserResultDto();

        try {

            User user = userService.createUser(userDto);

            //built result from user

        } catch (Exception e) {
            //transaction has already been rolled back.

            result.message = "User could not be created " + 
                             "because mail server caused error";
        }

        return result;
    }
}

Wenn Sie eine @Transaction Sie auf Ihrem controller die Methode, dass ist einfach nicht möglich.

InformationsquelleAutor der Antwort lanoxx