Pourquoi ne pas faire un contrôleur MVC printemps @Transactional?

j'ai vu les deux cas dans la pratique, dans des applications web de moyenne ou grande taille, en utilisant divers cadres web (JSP/Struts 1.x, GWT, JSF 2, avec Java EE et Spring).

d'après mon expérience, il est préférable de délimiter les transactions au niveau le plus élevé, c'est-à-dire au niveau du" contrôleur".

dans un cas, nous avons eu une classe BaseAction rallongeant les entretoises Action , avec une implémentation pour la méthode execute(...) qui manipulait La gestion des sessions d'hibernation (sauvegardée dans un objet ThreadLocal ), les transactions begin/commit/rollback, et la mise en correspondance des exceptions avec les messages d'erreur conviviaux. Cette méthode consiste simplement à annuler la transaction en cours Si une exception est propagée jusqu'à ce niveau, ou si elle est marquée uniquement pour l'annulation; sinon, elle déclenche la transaction. Cela a fonctionné dans tous les cas, où il y a normalement une seule transaction de base de données pour l'ensemble du cycle de requête/réponse HTTP. Les rares cas où plusieurs transactions étaient nécessaires et seraient traitées dans un code propre au cas d'utilisation.

dans le cas de GWT-RPC, une solution similaire a été mise en œuvre par une implémentation de Servlet GWT de base.

avec JSF 2, Je n'ai utilisé jusqu'à présent que la démarcation du niveau de service (en utilisant des haricots de Session EJB qui ont automatiquement "requis" la propagation de la transaction). Il y a ici des inconvénients, par opposition à la délimitation des transactions au niveau du JSF support beans. Fondamentalement, le problème est que dans de nombreux cas, le contrôleur JSF doit faire plusieurs appels de service, chacun accédant à la base de données de l'application. Pour les transactions au niveau de service, cela implique plusieurs transactions distinctes (toutes engagées, sauf exception), qui taxent davantage le serveur de la base de données. Ce n'est pas seulement un inconvénient de performance, cependant. Avoir plusieurs transactions pour une seule requête / réponse peut aussi conduire à des bugs subtils (Je ne me souviens plus des détails, juste que de tels problèmes ont fait produire.)

autre réponse à cette question parle de"logique nécessaire pour identifier la portée d'une base de données/transaction d'affaires". Cet argument n'a pas de sens pour moi, puisqu'il y a Non logique associée à la démarcation de transaction du tout, normalement. Ni les classes de contrôleur ni les classes de service n'ont besoin de réellement "connaître" les transactions. Dans la grande majorité des cas, dans une application web chaque opération commerciale se produit à l'intérieur d'une requête/réponse HTTP paire, avec la portée de la transaction étant toutes les opérations individuelles étant exécutées à partir du point de la demande est reçue jusqu'à ce que la réponse soit terminée.

à l'occasion, un service d'affaires ou un contrôleur peut avoir besoin de traiter une exception d'une manière particulière, alors marquez probablement la transaction actuelle pour le retrait seulement. En Java EE (JTA), ceci est fait en appelant UserTransaction#setRollbackOnly () . L'objet UserTransaction peut être injecté dans un champ @Resource , ou obtenu par programmation À partir d'un certain ThreadLocal . Au printemps, l'annotation @Transactional permet de spécifier le rollback pour certains types d'exception, ou le code peut obtenir un thread-local TransactionStatus et appeler setRollbackOnly() .

donc, à mon avis et selon mon expérience, rendre le contrôleur transactionnel est la meilleure approche.

Parfois, vous voulez annuler une transaction lorsqu'une exception est levée, mais en même temps vous voulez gérer l'exception de créer une réponse appropriée dans le contrôleur.

si vous mettez @Transactional sur la méthode controller la seule façon de forcer le roll-back pour lancer la transaction à partir de la méthode controller, mais alors vous ne pouvez pas retourner un objet de réponse normale.

mise à Jour: un rollback peut également être réalisé par programmation, comme indiqué dans Rodério's answer .

une meilleure solution est de rendre votre méthode de service transactionnel et ensuite gérer une exception possible dans les méthodes de contrôleur.

l'exemple suivant montre un service utilisateur avec une méthode createUser , cette méthode est responsable de créer l'utilisateur et d'envoyer un e-mail à l'utilisateur. Si l'envoi échoue, nous voulons rollback la création de l'utilisateur:

@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
    }
}

alors dans votre controller vous pouvez envelopper l'appel à createUser dans un try / catch et créer une réponse appropriée à l'utilisateur:

@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;
    }
}

si vous mettez un @Transaction sur votre méthode de controller ce n'est tout simplement pas possible.