org.hibernate.StaleStateException: Batch update returned unexpected row count from up

**Esil2008** · 25/06/2008, 16h42

Bonjour,
J'ai l'exception suivante qui est déclenchée de temps en temps

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
org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
	at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:61)
	at org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:46)
	at org.hibernate.jdbc.BatchingBatcher.checkRowCounts(BatchingBatcher.java:68)
	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:266)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
	at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
	at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
	at com.ulnet.memberarea.dao.OrderBook.DaoOrderBookImpl.updateTblTrade(DaoOrderBookImpl.java:905)
	at com.ulnet.memberarea.service.OrderBook.ServiceOrderBookImpl.updateTblTrade(ServiceOrderBookImpl.java:450)
	at com.ulnet.memberarea.OdiSysConnection.MonitoringLoader.updateTradeList(MonitoringLoader.java:1595)
	at com.ulnet.memberarea.OdiSysConnection.MonitoringLoader.run(MonitoringLoader.java:523)

L'exception est declenche quand j'essaye de commiter les modifications effectuees.
L'exception est donc déclenchè au niveau de cette fonction :

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
public void updateTblTrade(Trade trade) {
		Session session = HibernateUtil.getSessionFactory().getCurrentSession();
		try {
			session.beginTransaction();
			Tbltrade t = generateTbltrade(trade);
			if ( !isExist(t, session) ) {
				session.save(t);
				System.out.println("[Tbltrade Save]");
			}
			else {
				session.merge(t);
				System.out.println("[Tbtrade Merge]");
			}
			
			session.getTransaction().commit();
		}
		catch(Exception e) {
			session.beginTransaction().rollback();
			e.printStackTrace();
		}
	}

ici http://www.hibernate.org/hib_docs/v3...Exception.html ils disent quand ça arrive, mais pas comment y remédier.

Qlq'un à déjà eu le même problème.

Merci

**djsnipe** · 25/06/2008, 17h10

Un problème de versionning ne peut pas être géré automatiquement dans le cas général. Dans une application en mode TP, c'est l'utilisateur qui a fait des modifications sur des données, mais entre temps quelqu'un d'autre les à modifier. La solution consiste à prévenir l'utilisateur pour lui demander quoi faire : écraser les données ou afficher les nouvelles pour qu'il décide quoi faire.
En mode batch, on peut considérer le processus suivant : on charge une liste d'objets indépendants à traiter, on applique les traitements puis on persiste. En cas d'erreur de version, une stratégie peut être de recommencer le traitement pour la donnée en erreur ==> recharger automatiquement la dernière version, la traiter et la persister.

**Esil2008** · 25/06/2008, 17h29

L'application que je développe est une application web, donc je peux être amener à avoir plusieurs threads d'execution.
Dans le cas d'accès concurrents par exemple. Moi je voudrais écraser les données s'ils existent ! C'est pour ça que j'utilise le merge, au fait ni le update ni le saveorupdate ne marche dans mon cas, ça déclenche des exceptions de uniquekey ...

A ton avis comment dois je proceder pour éviter ce genre d'exception (staleStateException).

Meric

**djsnipe** · 25/06/2008, 17h56

De mémoire, cette exception n'est lancée que lorsque tes objets définissent un attribut "version" qui sert justement à la gestion de version. Sans version, plus de StaleStateException je pense, et donc le dernier arrivé à toujours raison.

**Esil2008** · 25/06/2008, 18h03

J'utilise pas de versionning, toujours quand je recois des donnes soit je les insère soit j'update !!!

**djsnipe** · 25/06/2008, 18h18

D'après la javadoc de l'exception :
Thrown when a version number or timestamp check failed, indicating that the Session contained stale data (when using long transactions with versioning). Also occurs if we try delete or update a row that does not exist.

Tu utilises peut être dans la même session deux instances d'objets différents, représentant la même ligne en BDD. Au moment du flush, hibernate ne saurait pas lequel des 2 objets prendre pour mettre à jour la BDD.

**Esil2008** · 26/06/2008, 09h50

J'ai qu'une seule instance à la fois. Tu peux voir le code que j'ai deja posté. J'ai même rajouté un synchronized pour prévenir des problèmes de concurrences mais le problèmes apparait tjrs de temps en temps

**djsnipe** · 26/06/2008, 10h01

Une seule à la fois oui, mais plusieurs appels à cette méthode se font dans la même Session Hibernate.

**Esil2008** · 26/06/2008, 10h31

Merci pour tes reponses djsnipe,
A ton avis qu'est ce que je dois faire pour éviter cela.
Je t'explique comment marche mon programme.
J'ai un programme (un thread de monitoring) qui se charge de récupérer des données envoyées par une autre application.
L'autre application envoie chaque fois un et seul objet mais en rafale (toutes les 30ms).
Dés reception de l'objet le même thread se charge d'appeler la couche Dao qui contient des méthodes d'accès à la base de données.
J'insiste que le seul programme qui fait des appels à la couche DAO est le thread de monitoring.

J'ai remarqué une chose bizar dans l'exécution de mon application. Quand je lance le programme en mode debug. Je met plusieurs points d'arrêt pour tracer son exécution. Hors il y a un truc fou qui se passe. Meme si mon appli est bloquée sur un point d'arrêt. Quand je reçois des données de l'autres application, la base de données change !!!!!!!
J'ai mit partout des system, le seul programme qui accède a la Dao c'est le thread de monitoring, mais il est arrête (bloqué/suspendu sur le point d'arrêt) ! et malgré ça mes tables sont mis à jour.
Je sais que c'est pas possible, mais c'est ce qui se passe. Pour l'instant j'ai aucune explication. J'ai vérifié les threads qui sont lancés, rien d'anormales...

Bref, peut être l'exception hibernate vient de ce probléme !

**djsnipe** · 26/06/2008, 10h47

Pour éviter tout problème dans la Session Hibernate, je te conseil sois de la purger après chaque appel (méthode "clean") je crois, sois d'utiliser une StatelessSession.

Ton thread de monitoring, est-tu certain qu'il soit unique ? Comment récupère-t-il les données envoyées par ton autre application ? Tu n'aurais pas une création de Thread à chaque appel ? Pour le point d'arrêt, si tu es dans Eclipse, tu peux demander dans les propriétés d'arrêter toute la VM, et pas uniquement le thread en cours, comme c'est le cas par défaut. C'est peut être effectivement un problème de concurrence.

**Esil2008** · 26/06/2008, 11h13

Salut,
Oui mon thread de monitoring est unique car je le crée à partir d'une classe singleton. Donc il y a une seule instance de ce programme qui tourne.
Effectivement j'utilise Eclipse et je vois bien dans la liste des threads qui tournent dans mon programme qu'il n'a rien d'anormal. Car j'ai donné des noms pour chacun de mes threads. J'en ai trois.
Un qui teste le connexion avec l'autre appli (avec des hearbeat)
Un autre qui écoute sur une socket partagé avec l'autre appli (c lui qui recoit les données)
Et enfin mon thread de monitoring qui accède à une hashTable mis à jour par le deuxième thread, elle contient toutes les données recues.

Pour le clear, je peux le faire apres le commit ?

**djsnipe** · 26/06/2008, 11h18

Envoyé par Esil2008

Pour le clear, je peux le faire apres le commit ?

Oui, et même surtout APRES le commit, sinon la Session sera vidée des données à modifier, et donc le flush de la session, déclenché lors du commit ne fera aucune modif en BDD.

Je pense qu'il faut absolument que tu détermine pourquoi tu as des modifs en BDD si ton thread de monitoring est suspendu.

**Esil2008** · 26/06/2008, 11h25

C'est sur il faudra que je trouve l'origine de ce probléme, car ça bouffe un peu de temps d'exec comme meme.
Maintenant comme j'ai rajouté partout des mécanismes de synchronisations pour gérer d'eventuel accès concurrents, j'ai plus la premiére exception, en tous cas pour le moment (après 2 ou 3 essais).
Par contre j'ai une autre exception

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
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:266)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167)
	at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
	at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
	at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
	at com.ulnet.memberarea.dao.OrderBook.DaoOrderBookImpl.updateTblTrade(DaoOrderBookImpl.java:909)
	at com.ulnet.memberarea.service.OrderBook.ServiceOrderBookImpl.updateTblTrade(ServiceOrderBookImpl.java:450)
	at com.ulnet.memberarea.OdiSysConnection.MonitoringLoader.updateTradeList(MonitoringLoader.java:1599)
	at com.ulnet.memberarea.OdiSysConnection.MonitoringLoader.run(MonitoringLoader.java:525)
Caused by: java.sql.BatchUpdateException: L'élément du batch 0 insert into tbltrades (trade_tableid, trade_time, trade_execqty, trade_price, trade_orderid, trade_id) values (NULL, 20080626-09:18:33.648, 50.0, 33.82, 11ac429c26e-001, OD_11ac42abfb6-000) a été annulé. Appeler getNextException pour en connaître la cause.
	at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2537)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1328)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:351)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2674)
	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)

elle se lance apres le commit de cette methode

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
public synchronized void updateTblTrade(Trade trade) {
		System.out.println("[Methode updateTbltrade] - Thread : " + Thread.currentThread().getName());
		Session session = HibernateUtil.getSessionFactory().getCurrentSession();
		try {
			session.beginTransaction();
			Tbltrade t = generateTbltrade(trade);
			if ( !isExist(t, session) ) {
				session.save(t);
				System.out.println("[Tbltrade Save]");
			}
			else {
				session.merge(t);
				System.out.println("[Tbtrade Merge]");
			}
 
			session.getTransaction().commit(); 
 
		}
		catch(Exception e) {
			session.beginTransaction().rollback();
			e.printStackTrace();
 
		}
	}

Moi je crois que c'est tjrs à cause de ce problème de concurrence. Même s'il y a un seul thread qui peut accéder à cette méthode (le monitoring).

Je vais essayer de rajouter des clear pour voir l'exec.
thanks

**Esil2008** · 26/06/2008, 11h32

apres le rajout des clear biensur apres le commit, il m'affiche l'exception suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
org.hibernate.SessionException: Session is closed!
	at org.hibernate.impl.AbstractSessionImpl.errorIfClosed(AbstractSessionImpl.java:49)
	at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1319)
	at sun.reflect.GeneratedMethodAccessor203.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301)
	at $Proxy0.beginTransaction(Unknown Source)
	at com.ulnet.memberarea.dao.OrderBook.DaoOrderBookImpl.updateTblOrder(DaoOrderBookImpl.java:888)
	at com.ulnet.memberarea.service.OrderBook.ServiceOrderBookImpl.updateTblOrder(ServiceOrderBookImpl.java:446)
	at com.ulnet.memberarea.OdiSysConnection.MonitoringLoader.updateOrderList(MonitoringLoader.java:1591)
	at com.ulnet.memberarea.OdiSysConnection.MonitoringLoader.run(MonitoringLoader.java:465)

j'ai eu la même exception hier quand j'ai essaye de faire le flush apres le commit. Pour bien vider la session.
voila ma méthode :

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
	public synchronized void updateTblOrder(Order order) {
		System.out.println("[Methode updateTblorder] - Thread : " + Thread.currentThread().getName());
		Session session = HibernateUtil.getSessionFactory().getCurrentSession();
			try {
				session.beginTransaction();
				Tblorder o = generateTBLOrder(order);
				updateExecutqty(o, session);
				if ( !isExist(o, session) ) {
					session.save(o);
					System.out.println("[Tblorder Save]");
				}
				else {
					List<Tblorder> result = session.createQuery("from Tblorder where order_id = '"+ o.getOrderId()+ "' ").list();
					Tblorder tbl = result.get(0);
					if ( tbl.getListOrderId() != null && !tbl.getListOrderId().equals(""))
						o.setListOrderId(tbl.getListOrderId());
					session.merge(o);
					System.out.println("[Tblorder Merge]");
				}
 
				session.getTransaction().commit();
				session.clear();
			}
			catch(Exception e) {
				session.beginTransaction().rollback();
				e.printStackTrace();
 
			}
		//}
	}

Et j'ai tjrs l'ancienne exception j'ai parlé trop vite

**djsnipe** · 26/06/2008, 11h54

Plusieurs choses :

As-tu activé le batch update ? Je pense que oui, sinon je crois tu n'aurais pas tes exceptions lors des commits, mais lors des opérations unitaires. Essayes de repasser la valeur à 0 pour l'instant.

Dans ton catch, tu créer un nouvelle transaction pour faire un rollback dessus. Ce n'est pas la bonne méthode, il faut faire un rollback sur la précédente transaction, et je pense que c'est l'origine de ton exception "Session is closed", car dans la stack on voit apparaitre une demande de nouvelle transaction.

Dans la stack précédente, une erreur de contrainte JDBC apparait, tu dois faire un save alors que l'objet existe déjà en BDD. Quel est le code de ta méthode isExists ?

**Esil2008** · 26/06/2008, 12h09

Merci pour ta réactivité,
Effectivement je viens d'ajouter cette ligne que j'avais pas de mon fichier de config Hibernate

Code :

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

<property name="hibernate.jdbc.batch_size">0</property>

il faut faire un rollback sur la précédente transaction

c'est ta dire

Code :

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

session.getTransaction().rollback();

???

Et voila le code de la methode isExist

Code :

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

1
2
3
4
5
6
public boolean isExist(Tblorder order, Session session) {
		List<Tblorder> result = session.createQuery("from Tblorder where order_id = '"+ order.getOrderId()+ "' ").list();
		if ( result.size() > 0)
			return true;
		else return false;
	}

Merci bien

**djsnipe** · 26/06/2008, 12h15

Envoyé par Esil2008

c'est ta dire

Code :

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

session.getTransaction().rollback();

???

Oui, c'est ça, tu dois annuler la transaction en cours.

OK pour la méthode isExist, même si tu peux l'optimiser un peut pour faire uniquement un count.

**Esil2008** · 26/06/2008, 12h22

re,
et bien j'ai changé ma méthode comme suite :

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
	public synchronized void updateTblOrder(Order order) {
		System.out.println("[Methode updateTblorder] - Thread : " + Thread.currentThread().getName());
		Session session = HibernateUtil.getSessionFactory().getCurrentSession();
			try {
				session.beginTransaction();
				Tblorder o = generateTBLOrder(order);
				updateExecutqty(o, session);
				if ( !isExist(o, session) ) {
					session.save(o);
					System.out.println("[Tblorder Save]");
				}
				else {
					List<Tblorder> result = session.createQuery("from Tblorder where order_id = '"+ o.getOrderId()+ "' ").list();
					Tblorder tbl = result.get(0);
					if ( tbl.getListOrderId() != null && !tbl.getListOrderId().equals(""))
						o.setListOrderId(tbl.getListOrderId());
					session.merge(o);
					System.out.println("[Tblorder Merge]");
				}
 
				session.getTransaction().commit();
				session.clear();
 
			}
			catch(Exception e) {
				//session.beginTransaction().rollback();
				session.getTransaction().rollback();
				e.printStackTrace();
 
			}
		//}
	}

et j'ai envlever la ligne

Code :

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

<property name="hibernate.jdbc.batch_size">0</property>

Mais j'ai toujours la même exception "org.hibernate.SessionException: Session is closed!
J'ai pas encore améliorer la methode isExist, je vais le faire mnt.
Merci

**Esil2008** · 26/06/2008, 15h14

Re,
Je viens de trouver l'origine du problème de concurrence. Il y avait au faite une autre application qui accéder à ma base de données. C'est pour ça qu'il y avait des modif, même quand mon appli été arrêté

.
Avec la résolution de ce problème. Toutes les exceptions que j'avais n'apparaissent plus oufffffffffffffffffff!

Merci bq djsnipe pour ta disponibilité.