Spring et transaction

Bonjour,

J'ai un petit soucis avec Spring.

J'utilise Spring pour mes transactions.

Voici une de mes méthodes transactionnelles :

Code:

---

1 2 3 4 5 6 7 8 9 10

@Transactional public void majUser(List users){   for (User user : users){ jdbcTemplate.update(requete); fireEvent(update); }   }

---

Ok, quand il y a une exception toute les mises à jours sont rollbacké ... HORMIS, ceux de mon evenement ... En effet si vous voyez mon code, je publie un evenement qui va modifier aussi ma base.

Mais le rollback ne fonctionne pas ... les modifs apporté par l'evenement sont toujours en base après une exception.

Si une personne pouvait m'aider sur ce pb, merci !;)

Citation:

---

Envoyé par Shogun

Ok, quand il y a une exception toute les mises à jours sont rollbacké ... HORMIS, ceux de mon evenement ... En effet si vous voyez mon code, je publie un evenement qui va modifier aussi ma base.

Mais le rollback ne fonctionne pas ... les modifs apporté par l'evenement sont toujours en base après une exception.

---

Salut,
Peux-tu nous montrer ce que fait exactement cette méthode fireEvent() et surtout quel est son attribut de transaction ? Ce comportement pourrait s'expliquer par le fait que pour cette méthode fireEvent() la transaction en cours est suspendue pour exécuter la méthode dans une nouvelle transaction (attribut REQUIRES_NEW). Ou peut-être que tu lances un nouveau thread qui du coup s'exécute en dehors de la transaction courante. Sinon je ne vois pas trop ce qui pour faire rollbacker juste une partie du traitement et pas l'autre tant que le tout s'exécute dans la même transaction.

Bon, j'ai une piste ...

Pour situer le context :
J'ai 2 bases A et B.
sur chacune des bases j'utilise un jdbcTemplate (org.apache.commons.dbcp.BasicDataSource).
Seule la base B a besoin d'être transactionnelle. (TransactionManager sur la datasource).

Le probleme se pose quand :
A est une base MySql(com.mysql.jdbc.Driver) et B MySql(com.mysql.jdbc.Driver)

Mais quand :
A est une base MS SQL Server (net.sourceforge.jtds.jdbc.Driver) et B MySql (com.mysql.jdbc.Driver)

Je n'ai pas le probleme .... Le rollback se fait a merveille !!!! 8O


Quelqun pourrait m'expliquer ?

Citation:

---

Envoyé par manblaizo

Salut,
Peux-tu nous montrer ce que fait exactement cette méthode fireEvent() et surtout quel est son attribut de transaction ? Ce comportement pourrait s'expliquer par le fait que pour cette méthode fireEvent() la transaction en cours est suspendue pour exécuter la méthode dans une nouvelle transaction (attribut REQUIRES_NEW). Ou peut-être que tu lances un nouveau thread qui du coup s'exécute en dehors de la transaction courante. Sinon je ne vois pas trop ce qui pour faire rollbacker juste une partie du traitement et pas l'autre tant que le tout s'exécute dans la même transaction.

---

Non, j'ai tracé le thread, il prend la même transaction ... Mais j'ai l'impression que Spring fait un commit avant mon rollback ...

Une chose est certaine, Spring ne gère pas les transactions distribuées. Et comme tu fais des mises à jour sur deux bases de données différentes, la transaction que tu déclares au niveau de ta méthode n'englobe pas les deux sources de données, mais seulement la base de données pour laquelle tu as défini le DataSource comme étant le TransactionManager. L'autre base de données lance sa propre transaction. Ce qui signifie que le comportement n'est pas prévisble du tout.
Pour résoudre ce problème, peut-être que tu devrais sortir ce fireEvent() de la transaction sur la première base de données, et n'exécuter les mises à jour dans la deuxième base que si la première transaction n'a pas été rollbackée.

Citation:

---

Envoyé par manblaizo

Une chose est certaine, Spring ne gère pas les transactions distribuées. Et comme tu fais des mises à jour sur deux bases de données différentes, la transaction que tu déclares au niveau de ta méthode n'englobe pas les deux sources de données, mais seulement la base de données pour laquelle tu as défini le DataSource comme étant le TransactionManager. L'autre base de données lance sa propre transaction. Ce qui signifie que le comportement n'est pas prévisble du tout.
Pour résoudre ce problème, peut-être que tu devrais sortir ce fireEvent() de la transaction sur la première base de données, et n'exécuter les mises à jour dans la deuxième base que si la première transaction n'a pas été rollbackée.

---

non, je ne fais que des mises à jour sur la base B ... La base A ne me sert qu'en lecture ...

En gros je lis la base A, puis je modifie la base B.
Ce que je pensais, c'est que toutes mes modifs sur la base B ne se faisait que dans une seule transaction, ce qui n'est pas le cas quand A est aussi une base MySql .... Je me retrouve avec des données à moitié commité (voir mon 1er post) alors que je veux rollbacker l'ensemble de mes modifs. Dans mon code, je ne force jamais de commit, je laisse le transactionManager de Spring de la base B gérer cela.

Mais quand A est une base MS SQL Server, cela ne le fait pas ... Mes rollbacks fonctionnent bien ... Alors que bon, je ne fais que la lire ... Faudrait m'expliquer :?
Spring s'embrouille les pinceaux avec 2 datasources du même type ?

OK, je comprends, mais même si tu fais juste une lecture dans la base A, cette lecture se fait bien à l'intérieur d'une transaction. Enfin, bon... Et ça donne quoi comme résultat si les deux bases sont MS SQL Server ?

Citation:

---

Envoyé par manblaizo

Une chose est certaine, Spring ne gère pas les transactions distribuées. Et comme tu fais des mises à jour sur deux bases de données différentes, la transaction que tu déclares au niveau de ta méthode n'englobe pas les deux sources de données, mais seulement la base de données pour laquelle tu as défini le DataSource comme étant le TransactionManager. L'autre base de données lance sa propre transaction. Ce qui signifie que le comportement n'est pas prévisble du tout.
Pour résoudre ce problème, peut-être que tu devrais sortir ce fireEvent() de la transaction sur la première base de données, et n'exécuter les mises à jour dans la deuxième base que si la première transaction n'a pas été rollbackée.

---

Si tu utilise JTA, tu peux faire des transactions sur plusieurs bases differente, meme JMS, JCA normalement

Citation:

---

Envoyé par Hikage

Si tu utilise JTA, tu peux faire des transactions sur plusieurs bases differente, meme JMS, JCA normalement

---

Oui, bien entendu, et du coup tu vas avoir besoin de migrer ton application vers un serveur d'applications ou intégrer un Transaction Manager stand-alone; en tout cas Tomcat tout seul avec les sources de données ne suffiraient pas. Parce qu'il faudrait aussi savoir qu'un JTA TransactionManager assure la coordination entre les différentes sources de données qui participent à une transaction, avec un Two-Phase Commit protocol qui introduit aussi sa petite surcharge au niveau des performances. Le protocole est optimisé au sein d'un serveur d'applications quand on fonctionne sur une seule base de données, à tel point que le commit se fait en une seule phase pour un gain en performance. Donc il faudrait bien savoir si ça vaut vraiment le coup d'introduire une implémentation JTA dans ton application, surtout si celle-ci reste modeste.
Mais en tous les cas, si tu déploies déjà sur un serveur d'applications, le mieux serait certainement que tu configures JTA pour ta gestion des transactions dans Spring, ça résoudrait sûrement le problème.

Citation:

---

Envoyé par manblaizo

OK, je comprends, mais même si tu fais juste une lecture dans la base A, cette lecture se fait bien à l'intérieur d'une transaction. Enfin, bon... Et ça donne quoi comme résultat si les deux bases sont MS SQL Server ?

---

Ah, j'ai pas testé sur 2 bases MS SQL ... justement je suis passé à 2 bases MySQL pour avoir la main dessus.

Citation:

---

Envoyé par manblaizo

Oui, bien entendu, et du coup tu vas avoir besoin de migrer ton application vers un serveur d'applications ou intégrer un Transaction Manager stand-alone; en tout cas Tomcat tout seul avec les sources de données ne suffiraient pas. Parce qu'il faudrait aussi savoir qu'un JTA TransactionManager assure la coordination entre les différentes sources de données qui participent à une transaction, avec un Two-Phase Commit protocol qui introduit aussi sa petite surcharge au niveau des performances. Le protocole est optimisé au sein d'un serveur d'applications quand on fonctionne sur une seule base de données, à tel point que le commit se fait en une seule phase pour un gain en performance. Donc il faudrait bien savoir si ça vaut vraiment le coup d'introduire une implémentation JTA dans ton application, surtout si celle-ci reste modeste.
Mais en tous les cas, si tu déploies déjà sur un serveur d'applications, le mieux serait certainement que tu configures JTA pour ta gestion des transactions dans Spring, ça résoudrait sûrement le problème.

---

Non justement c'est une application Stand-alone (un main qui s'execute ...). donc JTA on peut oublier ...

Autre element que je viens de constater.

Si A et B sont 2 bases MySQL sur la même machine géré par le même serveur MySQL => Probleme : rollback fait a moitié ...

Si A et B sont 2 bases MySQL mais sur 2 machines différentes : Je n'ai plus de probleme !

Si qqun peut m'expliquer ... :aie:

Bon j'ai trouvé mes tables n'étaient pas innoDb :aie: