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

Persistance des données Java Discussion :

[PersistenceContext] Lock timeout seulement avec un EntityManager Extended


Sujet :

Persistance des données Java

  1. #1
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut [PersistenceContext] Lock timeout seulement avec un EntityManager Extended
    Salut,

    Je réalise actuellement une application web qui utilise les lib suivantes (pour référence) :
    • Hibernate (3.5.6)
    • Spring (3.0.5)
    • JSF (2.1.1-b03)
    • MySQL (5.5.10)
    • mysql-connector-java (5.1.9)
    • c3p0 (0.9.1.2)


    Le tout sur un Tomcat 7.0.14

    Depuis quelques temps, je me tapais des lock wait timeout, mais jusqu'à présent, j'avais réussi à les contourner. Mais cette fois...

    Hier, j'ai découvert quelque chose d'intéressant, ces dead lock n'arrivent que lorsque mon EntityManager est annoté avec PersistenceContextType en Extended. Lorsque celui-ci est en Transaction, plus de problème du tout !!!

    Première question : Meuh pourquoi ça change quelque chose sur ce point ???

    Du coup au début, je me dis facile, je met l'EntityManager en Transaction et roulez jeunesse ! J'ai donc utilisé OpenEntityManagerInViewFilter pour ne plus avoir de LazyInitializationException. Tout se passe bien coté front (couche de présentation JSF), mais lorsque je tente de modifier une liste lazy coté service : Bim! De nouveau LazyInitizalizationException : pas de proxy ou session fermée.

    A savoir que tous mes services sont marqués comme étant Transactionnal.
    Deuxième question : Donc normalement, la session ne devrait pas être fermée, non ?

    Le dead lock (enfin c'est un lock timeout en fait) apparait lorsque je fais ce genre de modif :
    Code:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    //Code dans une transaction (dans un autre service, genre ServiceOnSenFout.java)
    Car c = new Car();
    [....]
    c = this.carService.create(c);
     
    Wheel w = new Wheel();
    [.....]
    w.setCar(c);
    w = this.wheelService.create(w);   //<===== Lock timeout
    Pour info, les relations sont définies dans les entités de cette manière :
    Car :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    @OneToMany(mappedBy="car")
    private List<Wheel> wheels;
    Wheel :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    @ManyToOne(fetch=FetchType.LAZY)
    @JoinColumn(name="ID_CAR")
    private Car car;
    Le truc bizarre, et que je vois MySQL qui semble locker l'enregistrement correspondant à c sur la dernière ligne (celle avec la flèche). Et au bout de 50 secondes qu'il n'a pas réussi à obtenir ce lock, il dégage (c'est le seul verrou qui apparaît dans MySQL).

    Donc voilà. Honnêtement, je n'en peux plus, je crois que j'ai tout essayé dans tout les sens, et c'est totalement bloquant pour la suite de mon projet. Qui plus est, ce genre de bloquage se retrouve à de nombreux endroits dans l'application... Je dois donc me planter quelque part de façon monumentale, mais où ?

    LTourist

  2. #2
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut Quelque précisions
    Pour info, j'ai récupéré les logs de MySQL, et repris toutes les requêtes qui constituent ma procédure. Lorsque je les mets dans un script et les exécute, il n'y a aucun blocage...

    Le blocage peut-il venir du coté Hibernate/JPA seulement ???

  3. #3
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut
    Un peu de neuf :
    Le lock timeout intervient car les deux requête create sont exécutées dans deux transactions différentes. Donc la deuxième attend la fin de la première pour faire son insert (à cause de la fk, elle doit lire l'enregistrement locké par la première transaction).

    Le problème est que toute ces méthodes sont marquées comme propagation = Propagation.REQUIRED, ce qui devrait faire l'ensemble de la procédure dans une seule transaction. Force est de constaté que ce n'est pas le cas...

    Quelqu'un saurait-il à quoi c'est dû, et éventuellement comment résoudre ça ? (REQUIRED = une seule transaction, pas 56!!!)

    EDIT : les différentes transactions JPA se rejoignent bien, cependant, plusieurs connexions sont prises dans le pool (c3p0) et ouverte dans MySQL. Ce mode de fonctionnement est normal dans JPA, mais ne devrait-il pas y avoir autant de transaction coté JPA que MySQL ?

  4. #4
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    214
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Avril 2011
    Messages : 214
    Points : 338
    Points
    338
    Par défaut
    Bonjour,

    D'après la doc de l'API:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    REQUIRED
              Support a current transaction, create a new one if none exists.
    Donc si une transaction existe il la réutilise mais sinon il en démarre une nouvelle.

    Si ce sont des méthodes de Service qui sont annotées avec @Transactional (je fais une hypothèse) et que c'est un contrôleur qui appelle ces différentes méthodes mais que ce contrôleur n'est pas "@Transactional" alors on risque en effet de se retrouver avec des transactions séparées.

    Si une méthode s'attend à ce qu'une transaction soit déjà en cours lorsqu'elle est appelée alors il vaut mieux utiliser MANDATORY

  5. #5
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut
    Citation Envoyé par -gma- Voir le message
    Bonjour,

    D'après la doc de l'API:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    REQUIRED
              Support a current transaction, create a new one if none exists.
    Donc si une transaction existe il la réutilise mais sinon il en démarre une nouvelle.

    Si ce sont des méthodes de Service qui sont annotées avec @Transactional (je fais une hypothèse) et que c'est un contrôleur qui appelle ces différentes méthodes mais que ce contrôleur n'est pas "@Transactional" alors on risque en effet de se retrouver avec des transactions séparées.

    Si une méthode s'attend à ce qu'une transaction soit déjà en cours lorsqu'elle est appelée alors il vaut mieux utiliser MANDATORY
    Merci de ta réponse.
    Tous mes services sont annotés @Transactional, ainsi que mes DAO. Les premiers sont REQUIRED tandis que les DAO sont MANDATORY justement.

    Le point d'entrée de ma procédure se trouve dans un service, et la transaction est donc bien démarrée.

    Comme je l'ai mis au dessus, je pense que le problème vient plus d'une fait que lorsqu'une transaction est démarré et rejoins la transaction existante, une nouvelle connection est tout de même prise dans le pool et ouverte avec MySQL (avec sa propre transaction, qui du coup produit le lock timeout).

    Ce mode de fonctionnement ressemble beaucoup à http://dev.mysql.com/doc/refman/5.5/en/xa.html, mais j'ai beau cherché, tout semble compatible avec ce mode dans ma chaine de connection à la BDD... A part peut etre c3p0, sur lequel je ne trouve pas d'infos concernant ce mode...


    On peut voir dans ce log le nombre de connections inutilisées baisser, a chaque fois, une nouvelle connection est ouverte dans MySQL (c'est un gros pavé je sais, mais si ça peut aider) :
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Creating new transaction with name [gpaf.services.impl.UserService.find]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; ''
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Opened new EntityManager [org.hibernate.ejb.EntityManagerImpl@15d4273] for JPA transaction
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Exposing JPA transaction as JDBC transaction [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@15c6c8d]
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 3, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Starting resource local transaction on application-managed EntityManager [org.hibernate.ejb.EntityManagerImpl@17cff66]
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Joined local transaction
    17 juin 2011 05:09:39 [main] org.hibernate.SQL - select user0_.ID as ID3_0_, user0_.droits as droits3_0_, user0_.hibernate_version as hibernate3_3_0_, user0_.login as login3_0_, user0_.password as password3_0_ from user user0_ where user0_.ID=?
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - cxnStmtMgr.statementSet( com.mysql.jdbc.JDBC4Connection@1195c2b ).size(): 1
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 1; num connections: 1; num keys: 1
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinStatement(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 0; num connections: 1; num keys: 1
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Initiating transaction commit
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Committing JPA transaction on EntityManager [org.hibernate.ejb.EntityManagerImpl@15d4273]
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 0; num connections: 1; num keys: 1
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 3, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 0; num connections: 1; num keys: 1
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 0; num connections: 1; num keys: 1
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 1; checked out: 0; num connections: 1; num keys: 1
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Closing JPA EntityManager [org.hibernate.ejb.EntityManagerImpl@15d4273] after transaction
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.EntityManagerFactoryUtils - Closing JPA EntityManager
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Creating new transaction with name [gpaf.services.impl.VersionApplicativeService.findLastVaVersionNumber]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; ''
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Opened new EntityManager [org.hibernate.ejb.EntityManagerImpl@c360a5] for JPA transaction
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Exposing JPA transaction as JDBC transaction [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@145c761]
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Found thread-bound EntityManager [org.hibernate.ejb.EntityManagerImpl@c360a5] for JPA transaction
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Participating in existing transaction
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 3, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Starting resource local transaction on application-managed EntityManager [org.hibernate.ejb.EntityManagerImpl@24c672]
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Joined local transaction
    17 juin 2011 05:09:39 [main] org.hibernate.SQL - select max(this_.VERSION) as y0_ from version_applicative this_
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - cxnStmtMgr.statementSet( com.mysql.jdbc.JDBC4Connection@dc1f04 ).size(): 1
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 2; checked out: 1; num connections: 2; num keys: 2
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinStatement(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 2; checked out: 0; num connections: 2; num keys: 2
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Initiating transaction commit
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Committing JPA transaction on EntityManager [org.hibernate.ejb.EntityManagerImpl@c360a5]
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 2; checked out: 0; num connections: 2; num keys: 2
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 3, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 2; checked out: 0; num connections: 2; num keys: 2
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 2; checked out: 0; num connections: 2; num keys: 2
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 2; checked out: 0; num connections: 2; num keys: 2
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Closing JPA EntityManager [org.hibernate.ejb.EntityManagerImpl@c360a5] after transaction
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.EntityManagerFactoryUtils - Closing JPA EntityManager
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - No local transaction to join
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [main] org.hibernate.SQL - select abaque0_.ID as ID0_0_, abaque0_.DATE_DEB as DATE2_0_0_, abaque0_.DATE_FIN as DATE3_0_0_, abaque0_.hibernate_version as hibernate4_0_0_, abaque0_.NOM as NOM0_0_ from abaque abaque0_ where abaque0_.ID=?
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - cxnStmtMgr.statementSet( com.mysql.jdbc.JDBC4Connection@dc1f04 ).size(): 2
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 3; checked out: 1; num connections: 2; num keys: 3
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinStatement(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 3; checked out: 0; num connections: 2; num keys: 3
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 3; checked out: 0; num connections: 2; num keys: 3
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinAll(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 3; checked out: 0; num connections: 2; num keys: 3
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Creating new transaction with name [gpaf.services.impl.VersionApplicativeService.createVa]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; ''
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Opened new EntityManager [org.hibernate.ejb.EntityManagerImpl@a37c6a] for JPA transaction
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 4, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Exposing JPA transaction as JDBC transaction [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@7881db]
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Found thread-bound EntityManager [org.hibernate.ejb.EntityManagerImpl@a37c6a] for JPA transaction
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Participating in existing transaction
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 3, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Starting resource local transaction on application-managed EntityManager [org.hibernate.ejb.EntityManagerImpl@24c672]
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Joined local transaction
    17 juin 2011 05:09:39 [main] org.hibernate.SQL - select max(this_.VERSION) as y0_ from version_applicative this_
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - cxnStmtMgr.statementSet( com.mysql.jdbc.JDBC4Connection@1195c2b ).size(): 2
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 4; checked out: 1; num connections: 2; num keys: 4
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinStatement(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 4; checked out: 0; num connections: 2; num keys: 4
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Joined local transaction
    17 juin 2011 05:09:39 [main] org.hibernate.SQL - select this_.ID as ID9_0_, this_.ID_ABAQUE as ID9_9_0_, this_.ANNEE as ANNEE9_0_, this_.DATE_MEP as DATE3_9_0_, this_.DATE_MES as DATE4_9_0_, this_.hibernate_version as hibernate5_9_0_, this_.PALIER as PALIER9_0_, this_.STATUT_VERSION as STATUT7_9_0_, this_.VERSION as VERSION9_0_ from version_applicative this_ where this_.VERSION=?
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - cxnStmtMgr.statementSet( com.mysql.jdbc.JDBC4Connection@1195c2b ).size(): 3
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 5; checked out: 1; num connections: 2; num keys: 5
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinStatement(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 5; checked out: 0; num connections: 2; num keys: 5
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Joined local transaction
    17 juin 2011 05:09:39 [main] org.hibernate.SQL - insert into version_applicative (ID_ABAQUE, ANNEE, DATE_MEP, DATE_MES, hibernate_version, PALIER, STATUT_VERSION, VERSION) values (?, ?, ?, ?, ?, ?, ?, ?)
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - cxnStmtMgr.statementSet( com.mysql.jdbc.JDBC4Connection@1195c2b ).size(): 4
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 6; checked out: 1; num connections: 2; num keys: 6
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinStatement(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 6; checked out: 0; num connections: 2; num keys: 6
    17 juin 2011 05:09:39 [main] org.hibernate.SQL - select processusa0_.ID_VERSION_APPLICATIVE as ID7_9_1_, processusa0_.ID as ID1_, processusa0_.ID as ID8_0_, processusa0_.DESCR as DESCR8_0_, processusa0_.DESC_SFG as DESC3_8_0_, processusa0_.hibernate_version as hibernate4_8_0_, processusa0_.NOM as NOM8_0_, processusa0_.REF_SFG as REF6_8_0_, processusa0_.ID_VERSION_APPLICATIVE as ID7_8_0_ from processus_applicatif processusa0_ where processusa0_.ID_VERSION_APPLICATIVE=?
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - cxnStmtMgr.statementSet( com.mysql.jdbc.JDBC4Connection@1195c2b ).size(): 5
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 7; checked out: 1; num connections: 2; num keys: 7
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkinStatement(): com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 7; checked out: 0; num connections: 2; num keys: 7
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Found thread-bound EntityManager [org.hibernate.ejb.EntityManagerImpl@a37c6a] for JPA transaction
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.JpaTransactionManager - Participating in existing transaction
    17 juin 2011 05:09:39 [main] com.mchange.v2.resourcepool.BasicResourcePool - trace com.mchange.v2.resourcepool.BasicResourcePool@5d855f [managed: 5, unused: 2, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1758cd1)
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Starting resource local transaction on application-managed EntityManager [org.hibernate.ejb.EntityManagerImpl@65394b]
    17 juin 2011 05:09:39 [main] org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler - Joined local transaction
    17 juin 2011 05:09:39 [main] org.hibernate.SQL - insert into processus_applicatif (DESCR, DESC_SFG, hibernate_version, NOM, REF_SFG, ID_VERSION_APPLICATIVE) values (?, ?, ?, ?, ?, ?)
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - cxnStmtMgr.statementSet( com.mysql.jdbc.JDBC4Connection@6d999a ).size(): 1
    17 juin 2011 05:09:39 [main] com.mchange.v2.c3p0.stmt.GooGooStatementCache - checkoutStatement: com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache stats -- total size: 8; checked out: 1; num connections: 3; num keys: 8
    17 juin 2011 05:10:30 [main] com.mchange.v2.c3p0.impl.NewPooledConnection - com.mchange.v2.c3p0.impl.NewPooledConnection@14b9a74 handling a throwable.
    java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction

  6. #6
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 936
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 936
    Points : 4 356
    Points
    4 356
    Par défaut
    jettez un coup d'œil sur cette discussion du forum jboss, il y a peut-être un élément qui vous éclairera.

  7. #7
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut
    Citation Envoyé par JeitEmgie Voir le message
    jettez un coup d'œil sur cette discussion du forum jboss, il y a peut-être un élément qui vous éclairera.
    Merci de la réponse, mais malheureusement ça ne m'aide pas beaucoup, vu que d'après les logs, les join transaction & ie se font correctement... le problème vient donc certainement de plus bas... Je pense notamment aux drivers MySQL ou à MySQL en lui-même (ça serait gros, mais je vois pas d'autres solutions )

  8. #8
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 936
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 936
    Points : 4 356
    Points
    4 356
    Par défaut
    Citation Envoyé par LTourist Voir le message
    Merci de la réponse, mais malheureusement ça ne m'aide pas beaucoup, vu que d'après les logs, les join transaction & ie se font correctement... le problème vient donc certainement de plus bas... Je pense notamment aux drivers MySQL ou à MySQL en lui-même (ça serait gros, mais je vois pas d'autres solutions )
    MySQL ne gère pas les transactions imbriquées et la discussion du forum en référence fait allusion à des incompatibilités entre EXTENDED et le mode de gestion de la session stateless/stateful à cause justement des frontières de transaction : donc quand vous dîtes que le problème est sans doute "plus bas", ce n'est pas faux, mais peut-être pas pour une question de "bug" dans le driver JDBC mais tout simplement de fonctionnalité limitée du RDBMS…

  9. #9
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut
    Citation Envoyé par JeitEmgie Voir le message
    MySQL ne gère pas les transactions imbriquées et la discussion du forum en référence fait allusion à des incompatibilités entre EXTENDED et le mode de gestion de la session stateless/stateful à cause justement des frontières de transaction : donc quand vous dîtes que le problème est sans doute "plus bas", ce n'est pas faux, mais peut-être pas pour une question de "bug" dans le driver JDBC mais tout simplement de fonctionnalité limitée du RDBMS…
    MySQL gère les transactions imbriquées, voir le lien du post précédent (enfin transactions distribuées=transactions imbriquées non ?) Je comptais justement tester le tout sur une base Oracle pour voir si ça fonctionnait mieux.

    J'ai toujours eu du mal avec les histoires stateless/statefull (c'est aussi pour ça que je voyais pas trop le rapport avec mon problème) mais il me semblait que c'était réservé lors de l'utilisation d'EJB ?

  10. #10
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 936
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 936
    Points : 4 356
    Points
    4 356
    Par défaut
    Citation Envoyé par LTourist Voir le message
    MySQL gère les transactions imbriquées, voir le lien du post précédent (enfin transactions distribuées=transactions imbriquées non ?) Je comptais justement tester le tout sur une base Oracle pour voir si ça fonctionnait mieux.

    J'ai toujours eu du mal avec les histoires stateless/statefull (c'est aussi pour ça que je voyais pas trop le rapport avec mon problème) mais il me semblait que c'était réservé lors de l'utilisation d'EJB ?
    par transaction imbriquées, j'entends
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    begin
        begin
        commit
    commit
    sur la même connection (ce que devrait faire un "vrai" REQUIRES_NEW…)

    une transaction distribuée c'est une transaction qui concerne plusieurs ressources…

  11. #11
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut
    OK, je pensais que ça revenait au même... Ce que vous décrivez ici revient à ce que fait justement mon REQUIRED, et c'est justement ce que je voudrais éviter (puisque ce qui est fait dans la deuxième transaction n'est pas visible par la première).

    Je suis en train de passer sur Oracle, voir si le problème est résolu avec ce SGBD.

  12. #12
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut
    Passer la base sur Oracle a résolu le problème
    Pas "normal", mais bon au moins ça marche

  13. #13
    Futur Membre du Club
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Points : 5
    Points
    5
    Par défaut
    Bon quelques news un peu tardive, mais ça peut être utile à d'autre.

    Le problème venait certainement en fait d'une utilisation d'un PersistenceContext en EXTENDED hors d'un contexte J2E (j'utilise Tomcat) et injecté par Spring.

    Dans ce cas, Spring semble injecter un PersistenceContext différent par DAO, ce qui fait qu'entre deux DAO, le cache de niveau 1 de JPA/Hibernate n'est pas partagé.

    Bien sur ça peut tout de meme fonctionner si la session est flushé dans la 1ere DAO avant d'appeler la seconde, puisque dans ce cas, le cache de niveau 2 est actualisé...

    Après au niveau des locks peut etre que du meme coup ils y a d'autres trucs qui s'embrouillent du fait de cette mauvaise gestion.

    Pour référence : http://favit.com/d/294U2/bozhos-tech-blog-spring-and

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

Discussions similaires

  1. Problème d'indexation avec Solr : write.lock timeout
    Par amalec78 dans le forum Autres
    Réponses: 1
    Dernier message: 21/09/2012, 14h10
  2. Réponses: 4
    Dernier message: 02/05/2008, 19h13
  3. Association seulement avec la clé, pas avec l'objet ?
    Par steve_toulouse dans le forum Hibernate
    Réponses: 6
    Dernier message: 24/10/2006, 14h25
  4. pb avec une classe extends JPanel
    Par thecancre dans le forum AWT/Swing
    Réponses: 9
    Dernier message: 11/05/2006, 18h45
  5. [8.2.1] SET CURRENT LOCK TIMEOUT lève une exception
    Par geoffrey_k dans le forum DB2
    Réponses: 2
    Dernier message: 28/11/2005, 09h24

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