Discussion :

[gwendal86]

Bonjour,

voici mon problème :

je charge des informations depuis une base mysql dans une interface gràce à hibernate.

Je fais des modifications en local (i.e. je ne modifie pas directement la base) par le biais de cette interface.

Et je sauve (bouton "sauver" ^^) dans la base.

Le problème est que si 2 personnes utilisent ce logiciel en même temps... ça foire car si (dans cet ordre) un utilisateur A supprime une entrée x et qu'un utilisateur B modifie cette même entrée x, alors au moment de la sauvegarde de B, il va y avoir un problème car x n'existe plus.

Les solutions que j'envisage sont,

- Bloquer la base entière pour un seul utilisateur, mais je ne vois pas comment (la fonction TABLE LOCK de MySql ne semble pas appropriée)

- Vérifier avant de sauvegarder que l'état de la base n'a pas été modifié et, le cas échéant, message d'erreur : "attention, base modifié, blabla" (le principe étant que le logiciel ne devant, dans un usage normal, n'être utilisé que par une personne à la fois)
Cette solution me semble la plus satisfaisante mais je ne vois pas comment faire pour savoir si la base à été modifiée depuis la dernière sauvegarde à part en créant un gros objet "Base" au chargement et en le comparant à un autre objet "Base" qui serait obtenue en faisant un chargement préliminaire avant toute sauvegarde... J'aimerai VRAIMENT qu'il y ait une autre solution

Donc si vous avez des idées pour savoir si une base à été modifiée, pour autoriser une seule entité (homme, programme) à accéder à une base ou toute autre idée je vous en serais gré.

MERCI

[plsavary]

Je fais des modifications en local (i.e. je ne modifie pas directement la base) par le biais de cette interface.

Je ne comprend pas vraiment ce que ça veut dire. Est-ce que les utilisateurs modifient la base de puis une application client lourd ?

Ou est-ce que les utilisateurs se connectent à une appli web ? Si c'est le cas hibernate doit résoudre ce problème.

[gwendal86]

en gros je ne travail pas directement avec des objets hibernate.

Je créé les objets dont j'ai besoin au chargement, ensuite l'utilisateur peut faire toutes les modif qu'il veut sur ces objets (transparent pour lui bien sur) et c'est seulement quand l'utilisateur sauve que je construit des objets hibernate pour mettre à jour la base.

le principe de fonctionnement c'est :


ouverture base
|
| ---> extraction des données
|
fermeture base

||
|| --- modif ...
||

ouverture base
|
| <--- remplissage de la base
|
fermeture base



Et l'idée, c'est qu'il faudrait que pendant la période "modif", personne ne touche à la base ou, si c'est impossible de faire ça simplement,
au moins empêcher la phase "remplissage de la base" si la base à été modifiée.

[plsavary]

Quelle est la raison de ce fonctionnement ?
Est-ce que ce n'est pas plus simple d'effectuer les modifications sur les objets Hibernate directement ?

[OButterlin]

Effectivement, c'est un curieux comportement...

Tu pourrais peut-être utiliser un verrouillage des enregistrements avant écriture.
Dans l'idée, ta lecture initiale est bien évidemment non bloquante mais avant écriture (physique), tu recharges les entités avec verrouillage

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
 
// le chargement
UnObjet monObjet = session.load(UnObjet.class);
 
// les modifications (on pourrait fermer la session)
 
// à la fin
session.beginTransaction();
 
// on boucle sur tous les objets à traiter...
session.load(monObjet.getClass(), maCle, LockMode.UPGRADE);
 
// on boucle sur tous les objets à mettre à jour
session.update(monObjet);
 
session.getTransaction().commit();

et au commit -> tout se libère
(si ça ne suffit pas, il faudra fermer la session)

C'est une idée... j'ai rien d'autre en stock pour le moment

[djsnipe]

Tu as différentes façon de gérer la concurrence :

1) Pas de verrouillage : le dernier qui parle à raison
2) Verrouillage optimiste : chaque enregistrement de chaque table possède un numéro qui correspond à la version de l'enregistrement. Une tentative de modification sur un numéro incrémenté depuis doit se traduire par une erreur (StateStaleException de mémoire avec Hibernate)
3) Verrouillage pessimiste : consiste à poser un verrou pour la modification. Personne ne peux modifier si la personne ayant posé le verrou n'a pas terminé. Ce qui peut etre tres tres génant si un utilisateur veut consulter une donnée sans la modifier. Il faut prévoir à ce moment là des écrans dédiés à la consultation qui ne posent pas de verrou, ou bien un bouton "modifier" pour poser le lock uniquement lors d'une modif (c'est également le moment de vérifier si les données n'ont pas changées en base pour rafraichir les données affichées).

Une solution élégante peut être de gérer ca de manière applicative, avec une table de "locks". C'est plus long à coder qu'un lock en bdd, mais ca permet de savoir facilement quel utilisateur possède le lock, de pouvoir forcer à prendre le verrou, de gérer un timeout sur le lock ....

Au final, le choix dépend du type d'application et de la fréquence des mises à jour simultanées.

En esperant t'avoir aidé