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

Version imprimable

Voir 40 message(s) de cette discussion en une page

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

Code:

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:

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

25/06/2008, 17h10
djsnipe

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.
25/06/2008, 17h29
Esil2008

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
25/06/2008, 17h56
djsnipe

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.
25/06/2008, 18h03
Esil2008

J'utilise pas de versionning, toujours quand je recois des donnes soit je les insère soit j'update !!!
25/06/2008, 18h18
djsnipe

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.
26/06/2008, 09h50
Esil2008

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
26/06/2008, 10h01
djsnipe

Une seule à la fois oui, mais plusieurs appels à cette méthode se font dans la même Session Hibernate.
26/06/2008, 10h31
Esil2008

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 !
26/06/2008, 10h47
djsnipe

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.
26/06/2008, 11h13
Esil2008

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 ?
26/06/2008, 11h18
djsnipe

Citation:

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.

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:

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:

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

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

Code:

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:

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 :oops:

26/06/2008, 11h54
djsnipe

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 ?

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

Code:

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

Citation:

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

c'est ta dire

Code:

session.getTransaction().rollback();

???

Et voila le code de la methode isExist
Code:

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

26/06/2008, 12h15
djsnipe

Citation:

Envoyé par Esil2008

c'est ta dire

Code:

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.

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

Code:

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:

<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

26/06/2008, 15h14
Esil2008

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! :mrgreen:

Merci bq djsnipe pour ta disponibilité.
26/06/2008, 17h42
djsnipe

Je t'en prie :mrgreen:

Voir 40 message(s) de cette discussion en une page