Pas d'update après un flush

Bonjour,

Dans une application utilisant JPA (hibernate) pour persister nos données, nous avons mis en place un DAO générique avec, entre autre, une méthode "save" dont le but est de sauver un objet, qu'il soit managé ou non par hibernate.

L'implémentation est la suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public class AbstractGenericDao<T extends Identifiable> { ... @PersistenceContext(unitName="AppPeristanceUnit") protected EntityManager em = null; ... @Transactional(readOnly = false) public T save(T entity) { if (entity.getId() == null) { em.persist(entity); em.flush(); return entity; } else { T newEntity = em.merge(entity); em.flush(); return newEntity; } }

---

Jusqu'à présent il a toujours bien fonctionné.
Mais récemment, dans une application qui importe des données j'ai eu des problèmes de modification non sauvées, et ce malgré le flush.
La table source de l'import comprend un champ qu'on flag pour savoir si l'enregistrement a été importé.
Les enregistrements étaient importés par paquet de 50 et en changeant ce nombre à 1, j'ai constaté qu'après un certain temps, l'importer se mettait à importer en boucle le même enregistrement car son flag n'était pas sauvé.
Dans le log de l'application je ne vois plus la requête d'update (qui était présente avant qu'il se mette à boucler), j'en conclus donc que ma méthode save n'a pas bien fait son boulot ...
Mais pourquoi ... ?

Il semblerait que mon problème est dû à des accès concurrent.

Dans mon environnement de test, si je lance l'importation seule, aucun problème.
Mais si je lance l'importation et que pendant qu'elle tourne je modifie les données en cours d'import, l'importation se bloque sur l'instruction d'update et reprend dès que je commit les modification dans Oracle SQL developper :

- update 86 records dans Oracle SQL developper
- commit
- démarrage de l'importer
- update des même 86 records
- importer bloqué sur l'instruction d'update (la requete SQL est loggué dans la console)
- commit
- reprise de l'import mais en boucle sur un record.

Je n'ai pas la moindre idée du comment régler ça :cry:

J'ai trouvé un dépannage :

c'est pas optimale mais pour le moment ça à l'air de tenir :

juste avant de valoriser le flag et de sauver le record, je le refresh (entityManager.refresh).

Le bémol, c'est que cette façon de géré ne tient pas compte des éventuelles modifications qui auraient pu être faites. (le record ne sera pas ré-importé avec les nouvelles modifications.)

je comprend pas trop ton souci du fait que c'est toi qui bloc le programme en vérrouillon la table par un update dans plsqldevelopper ??

En environnement réel, la table des données à importé est modifiée par une programme tiers.
Mon programme d'import est planifié pour tourner toutes les 2 minutes.

Pour reproduire le problème en environnement de test, je met à jour cette table en exécutant manuellement une requête d'update dans SQL Developper pendant que mon import tourne.

Au moment ou j'exécute ce query, mon importer va se bloquer sur la requête d'update de la même table (probablement un système de verrou sur les accès concurrent)

Et c'est seulement lorsque je vais commit dans SQL developper que l'importer rependre son cours (mais en bouclant sur le même record)

Le problème n'est pas le bloquage, car en stuation réelle, les commits sont fait immédiatement. Le problème c'est qu'après ce commit, mon importer s'embrouille et boucle sur le même record.

Je ne sais pas si c'est plus clair :?

Comment gères tu tes transactions ?
Il y a des chances que le problème vienne de là.

Déjà, poser un attribut transactionnel sur ta méthode save, je ne vois pas trop l'intérêt.

Alors,
d'abord je charge le record à importer en DB (pas de transaction)
Ensuite une transaction (non read-only) est ouverte pour chaque record à importer.
Si l'import réussi, je sauve le statut du record ("done") dans la transaction.
Si l'import échoue, je roll-back et sauve le status de l'import ("error") en dehors de cette transaction.

L'attribut transactionnel sur la méthode save à pour but de permettre l'écriture. Si je ne le mets pas, il n'y aura jamais de persistance, par défaut les transactions sont ouverte en "readOnly=true"

Peux-tu nous donner un peu plus de code, car j'ai du mal à tout comprendre.

Quand je dis que l'attribut transactionnel est mal placée, c'est quand général, on le place à un niveau plus haut, sur un service qui utilise un ou plusieurs accès en base selon les besoins. On ne doit pas faire, un accès en base, une transaction, sinon le concept de transaction n'a plus de sens.

La classe qui effectue l'import (ultra simplifiée):

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 33 34 35 36 37 38 39

@Service("awlTaskImporter") public class AwlTaskImporter implements IAwlTaskImporter { @Autowired private IAwlTaskManager awlTaskManager; // plein de manager // ...   // code business de l'importer public DataExchangeStatus run() { if(this.dataSource != null) { this.dataSource.open(); AwlTask task = null; boolean errorOccurs = false; while(this.dataSource.hasNext()) { task = this.dataSource.next(); try { this.importTask(task); } catch (Exception e) { errorOccurs = true; } if(errorOccurs) { // on flag le redord a E pour signifier l'erreur task.setRecordUpdated("E"); this.awlTaskManager.save(task); } } this.datasource.close(); } }   @Transactional(readOnly=false, rollbackFor=Throwable.class) public void importTask(AwlTask awlTask) throws Throwable { // toute la logique d'import vers les autres tables de la DB // ... awlTaskManager.refresh(awlTask); // <--- rajout de cette ligne pour éviter les boucles infinie sur le même record. awlTask.setRecordUpdated("N"); // on flag le record pour signifier qu'il a été importé awlTaskManager.save(awlTask); } }

---

"IAwlTaskManager" est ici juste un proxy vers la classe DAO postée précédemment

Le datasource :

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 33 34

@Service("awlTaskDatasource") public class TaskDataSource implements DataSource<AwlTask> {   @Autowired private IAwlTaskManager taskManager;   private Iterator<AwlTask> iterator = null;   public void open() throws Exception {   }   public void close() throws Exception {   }   public boolean hasNext() { if(this.iterator == null || !this.iterator.hasNext()) { this.loadTasks(); }   return this.iterator.hasNext(); }   public AwlTask next() { return this.iterator.next(); }   private void loadTasks() { // importe les taches dont le champ recordUpdated = "Y" // importe les taches par paquet de : 1 tache this.iterator = taskManager.getTasksToImport(1).iterator(); } }

---

La raison pour laquelle le transactionnal est mis sur la méthode save du DAO c'est que c'est un DAO générique utilisé par l'importer, mais pas uniquement. C'est une classe mère très largement utilisée, et on ne peut pas prédire s'il est toujours appelé dans un contexte où l'écriture est permise. Donc on l'a annotée de la sorte pour garantir que sont utilisation persistera les données.
Mais je suis ouvert à toute meilleures façon de faire.