Discussion :

[livenono]

Salut

J'utilise depuis peu warp persist et un frameworkd d'un ami et tous deux utilisent une annotation @Transactional, qui s'occupe de l'ouverture/fermeture des transactions sur une méthode.

Ainsi on est sûr que celle ci tourne dans une transaction, avec ce que cela implique de commit si la fin de la méthode est atteinte.

Je ne comprends pas trop par contre comment sont gérés les rollbacks. Un exemple concret est sur une méthode @Transactional save(Entity e). Si jamais pour une raison ou une autre celle ci échoue, que ce passe t il ? La sauvegarde est rollbacké et mon code continu ? N'y a t il pas des risques que je considère l'entité comme sauvée alors qu'elle ne l'est pas ?

Comment gérez vous vous même ce genre d'annotation ? Quel est leur meilleur usage ?

merci !
@+
nono

[gronono]

Bonjour,

Dans une méthode annotée transactionnal, le commit se fait si la méthode ne renvoie pas d'exception. Dans le cas contraire, elle fait un rollback et l'exception est remonté à l'appelant.

Donc dans le cas du rollback, ton entity n'est pas sauvegardée en base. Et tu as une Exception.

(Dans le cas de Spring, par défaut, seuls les RuntimeException provoquent un rollback).

[livenono]

merci !

je me suis dit la même chose depuis, et je me disais que je tenterai bien la chose pour voir comment se comporte mon appli web. J'imagine que l'idéal serait que toutes les modifs précédentes soient rollbackées, mais je ne suis pas certain que cela se passe ainsi.

A priori je suis dans le cas d'une stratégie "open session in view" : si pendant la session deux méthodes avec @Transactional sont appelées et que la 2eme plante, la 1ere est elle rollbackée aussi ?

@+
nono

[gronono]

A priori je suis dans le cas d'une stratégie "open session in view" : si pendant la session deux méthodes avec @Transactional sont appelées et que la 2eme plante, la 1ere est elle rollbackée aussi ?

Ca dépend de la stratégie de propagation définie. Par défaut, je crois que oui.

[livenono]

Hum, faut que je vérifie aussi ce second point. Pour le premier, et l'histoire de l'exception en cas d'erreur lors de la transaction, je confirme.

[gronono]

Sur le projet sur lequel je travaille, on utilise propagation = Propagation.REQUIRED. Dans cette stratégie, si une erreur provient dans la seconde méthode, alors la première est aussi "rollbackée".

D'après les sources org.springframework.transaction.annotation.Transactional, il s'agit de la stratégie par défaut.

Gronono