Discussion :

[Fractaliste]

Bonjour,


J'ai développé une interface client/serveur à l'aide d'hibernate qui interroge une base de donnée distante Derby.

J'ai une entité que j'update en masse, et j'ai de temps en temps une erreur de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
GRAVE: could not update hi value in: hibernate_unique_key
java.sql.SQLTransactionRollbackException: Aucun verrou n'a pu être obtenu à cause d'un interblocage ; le cycle de verrous et d'unités en attente est :
Lock : ROW, HIBERNATE_UNIQUE_KEY, (1,7)
  Waiting XID : {7044, U} , APP, update hibernate_unique_key set next_hi = ? where next_hi = ?
  Granted XID : {7043, S} 
Lock : ROW, HIBERNATE_UNIQUE_KEY, (1,7)
  Waiting XID : {7043, X} , APP, update hibernate_unique_key set next_hi = ? where next_hi = ?
  Granted XID : {7043, S} , {7044, S} 
. L'instruction SQL que le moteur de la base de données a choisi de supprimer est XID : 7044.
	at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
	at org.hibernate.id.TableGenerator.doWorkInCurrentTransaction(TableGenerator.java:157)
	at org.hibernate.engine.TransactionHelper$1Work.doWork(TransactionHelper.java:38)
	at org.hibernate.engine.transaction.Isolater$JdbcDelegate.delegateWork(Isolater.java:187)
	at org.hibernate.engine.transaction.Isolater.doIsolatedWork(Isolater.java:43)
	at org.hibernate.engine.TransactionHelper.doWorkInNewTransaction(TransactionHelper.java:51)
	at org.hibernate.id.TableGenerator.generate(TableGenerator.java:94)
	at org.hibernate.id.TableHiLoGenerator.generate(TableHiLoGenerator.java:62)
	at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:99)
	at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
	at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
	at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:618)
	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:592)
	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:596)
	at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220)
	at plansdesurveillance.DAO.Entity_Liaison_Ligne_PS_DérouléJpaController.create(Entity_Liaison_Ligne_PS_DérouléJpaController.java:48)
	at plansdesurveillance.controle.Controle_PS_Déroulé.UpdateLignes(Controle_PS_Déroulé.java:313)
	at plansdesurveillance.controle.Controle_PS_Déroulé.run(Controle_PS_Déroulé.java:76)
	at java.lang.Thread.run(Thread.java:662)

Donc visiblement le problème est un inter-blocage dont mon moteur SGBD n'arrive pas à se tirer et donc il tue une des instructions bloquante au hasard.

J'ai vu que quelqu'un avait déjà eu un problème similaire : http://www.developpez.net/forums/d52...jb3-glassfish/ Mais ça ne fonctionne pas chez moi car c'est toujours sur une requête UPDATE qu'il bloque (visiblement celle qui sert à déterminer la prochaine clef primaire...)

J'ai aussi trouvé ces quelques infos (http://wiki.apache.org/db-derby/LockDebugging) mais sans pour autant trouver de solutions...

Est-ce qu'en changeant ma détermination automatique de clef primaire ça pourrait changer quelque chose ? :/

Bon weekend
Raphaël N.

[fr1man]

Montre nous un peu de code :
Celui de la requête et celui de l'entité, et ton code de génération de clé.

[Allensan]

Donne nous plus d'informations aussi.
J'utilise pas Derby mais j'ai eu ce problème sur MSSQL 2008.

Sa peut venir de plein de chose , transaction trop longue, base de donnée sur un serveur fatigué.
Il serait bon de savoir combien tu a d'appelle a ces données dans ce même laps de temps plus ou moin 20 secondes.

[Fractaliste]

Montre nous un peu de code :
Celui de la requête et celui de l'entité, et ton code de génération de clé.

C'est une génération automatique de clef que j'utilise. Je n'ai donc pas accès au code en lui même, c'est Hibernate qui s'en occupe à moins que ce soit le driver Derby.

Je n'ai pas le code de mes entités sur moi. Toutes mes entités fonctionnent avec la même génération automatique de PK. Et j'ai déjà persisté 5 ou 6 milliers de lignes (en plusieurs mois bien entendu) avant que ça plante. Du côté de mon appli il n'y a pas de requête, j'utilise le persist() d'Hibernate. En revanche Hibernate doit sûrement transformer ça en requête Insert.

Sa peut venir de plein de chose , transaction trop longue, base de donnée sur un serveur fatigué.
Il serait bon de savoir combien tu a d'appelle a ces données dans ce même laps de temps plus ou moin 20 secondes.

En général il s'agit d'une entité que je persiste 200 par 200. Je n'ai jamais pensé à regarder combien de temps ça me prenait, je partais du principe qu'Hibernate gérais plusieurs transactions en même temps. Mais visiblement dans certaines limites. N'empêche ça me surprend qu'un inter-blocage soit possible sur un SGBD, c'est quand même une des contraintes principales prises en compte lors de leur développement.


J'avais posé ce problème il y a un mois car il s'était présenté à plusieurs occasions. Mais depuis deux semaines il a disparu. Je crois les doigts pour que cela ne se représente plus d'ici qu'on passe sur une base Oracle.