IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Spring Java Discussion :

Spring et transaction [Data]


Sujet :

Spring Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Inscrit en
    Avril 2003
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Avril 2003
    Messages : 129
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 !

  2. #2
    Membre chevronné
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : Janvier 2006
    Messages : 365
    Par défaut
    Citation Envoyé par Shogun Voir le message
    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.

  3. #3
    Membre confirmé
    Inscrit en
    Avril 2003
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Avril 2003
    Messages : 129
    Par défaut
    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 !!!!


    Quelqun pourrait m'expliquer ?

  4. #4
    Membre confirmé
    Inscrit en
    Avril 2003
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Avril 2003
    Messages : 129
    Par défaut
    Citation Envoyé par manblaizo Voir le message
    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 ...

  5. #5
    Membre chevronné
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : Janvier 2006
    Messages : 365
    Par défaut
    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.

  6. #6
    Membre confirmé
    Inscrit en
    Avril 2003
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Avril 2003
    Messages : 129
    Par défaut
    Citation Envoyé par manblaizo Voir le message
    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 ?

  7. #7
    Membre chevronné
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : Janvier 2006
    Messages : 365
    Par défaut
    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 ?

  8. #8
    Rédacteur
    Avatar de Hikage
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    1 177
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 1 177
    Par défaut
    Citation Envoyé par manblaizo Voir le message
    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
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  9. #9
    Membre chevronné
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : Janvier 2006
    Messages : 365
    Par défaut
    Citation Envoyé par Hikage Voir le message
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Data] spring / ibatis / @Transactional
    Par benibur dans le forum Spring
    Réponses: 4
    Dernier message: 09/07/2010, 14h52
  2. Hibernate-Spring Aucune transactions
    Par Takis dans le forum Hibernate
    Réponses: 6
    Dernier message: 17/04/2009, 11h31
  3. [Data] Spring JCA Transaction
    Par helios2092 dans le forum Spring
    Réponses: 0
    Dernier message: 02/12/2008, 17h43
  4. [Spring][Hibernate] Transaction déclarative
    Par mauvais_karma dans le forum Hibernate
    Réponses: 13
    Dernier message: 03/07/2008, 17h09
  5. [Data] [Spring][Ibatis] transactions non prise en compte
    Par nannous dans le forum Spring
    Réponses: 15
    Dernier message: 27/11/2007, 18h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo