Discussion :

[Warest]

Bonjour,

J'essaye d’effacer des entités de ma base de données mais la requête JPQL ne semble rien faire, pas de suppression, mais pas d'exception non plus.

Pourtant, dans un test unitaire la requête s'exécute bien.

J'ai pensé à un problème de transaction, une exception plus loin dans le code annulerait le delete mais j'ai annoté la méthode TransactionAttributeType.REQUIRES_NEW et le problème persiste.

Pourtant le résultat du executeUpdate() est cohérent mais rien n'est reflété sur la base de données.

Voici le code :

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
 
        @Override
	@TransactionAttribute(value=TransactionAttributeType.REQUIRES_NEW)
	public int deleteBetweenDate(Machine<?> machine, LocalDateTime startDate, LocalDateTime endDate) {
		Query q = em.createQuery(
				"DELETE FROM DAT9011FileData f "
				+ "WHERE f.date BETWEEN :startDate AND :endDate "
				+ "AND f.machine = :machine");
		q.setParameter("startDate",  startDate);
		q.setParameter("endDate",  endDate);
		q.setParameter("machine", machine);
		int linesRemoved = q.executeUpdate();
		em.flush();
		return linesRemoved;
	}

J'utilise ce code dans GlassFish 4.1 qui utilise EclipseLink comme fournisseur JPA. Je précise que dans le code ci-dessus "linesRemoved" correspond au bon nombre de lignes qui auraient du être supprimées, mais dans la bdd, aucun changements.

Quelqu'un aurait une idée ou une piste ?

Merci d'avance!

[tchize_]

Il faudrait que tu active dans ton implémentation JPA l'affichage des commandes SQL.

Deux possibilités:

1) la transaction n'est pas commité mais rollback
2) comme tu fais le DELETE en HQL mais que les entité correspondantes existent probablement dans l'entitymanager, l'autre transaction recrée ces entité lors du commit. Pour faire proprement normalement tu dois evict() les entités concernée de ton entitymanager pour qu'il n'essaie pas de les sauver.

[Warest]

Bonjour tchize_ et merci pour ton aide.

J'ai activé la journalisation pour y voir plus clair, je communiquerai les résultats des que le problème se reproduira.

1) la transaction n'est pas commité mais rollback

Etant donné que la méthode est annotée "TransactionAttributeType.REQUIRES_NEW" et qu'elle ne génère pas d'exception, quelle pourrait être les causes d'un rollBack ?

2) comme tu fais le DELETE en HQL mais que les entité correspondantes existent probablement dans l'entitymanager, l'autre transaction recrée ces entité lors du commit. Pour faire proprement normalement tu dois evict() les entités concernée de ton entitymanager pour qu'il n'essaie pas de les sauver.

Une partie des entités concernée par ce DELETE ne se trouve pas dans l'entity manager, une autre partie s'y trouve probablement. Mais aucune entité n'est supprimée.

[Warest]

C'était finalement le premier cas qui se produisait :

1) la transaction n'est pas commité mais rollback

Le delete affectait énormément d'entrées ( plusieurs million) et je finissait avec un :

[ejb.tx_timeout] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=202 _ThreadName=ScanMachine-managedThreadFactory-Thread-14] [timeMillis: 1537773803151] [levelValue: 900] [[
EJB5123:Rolling back timed out transaction

J'ai contourné le problème en effectuant les delete par plus petit morceaux. Pour ceux que ça intéresse je suis tombé sur un article expliquant comment optimiser les delete/update sur beaucoup d'enregistrements :

http://mysql.rjweb.org/doc.php/delet...ting_in_chunks