Discussion :

[n!co]

Bonjour,

Je developpe une application pour des séances de formation.
Durant une séance de formation, chaque personne se connecte à l'application via son login. Après avoir choisi la feuille d'exercice correspondante à la séance, un numéro doit lui être attribué et stocké dans une table seance_runtime (id_juge, id_seance, date_debut, date_fin et le numéro).
La première personne recoit le numéro 1, puis le second le numéro 2 et ainsi de suite mais il n'y a pas d'ordre prédéfini par personne physique.

Je n'arrive pas a visualiser comment je vais pouvoir incrémenter ce numéro sans avoir un risque d'accès concurrent et que deux personnes ait le même numéro.

Détail , chaque application est une appli desktop distincte et elles ne partagent rien mise à part la base de données finale.

Merci d'avance pour vos lumières
Nico

[fr1man]

Si c'est une simple valeur incrémentée, tu peux régler le problème avec l'utilisation d'une séquence de ta base de données, si elle les supporte.
Il n'y aura plus de risques d'avoir deux valeurs égales.

[n!co]

Oui effectivement j'y avais même pas pensé mais vu que je suis sous MySql ca pas le faire pour moi
Je suis entrain de regarder du coté des LOCK, mais j'y connais pas enorme.

Edit :

SI je mets un lock en ecriture sur la table.
et que je fais une requete du style :

Code :

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

INSERT INTO seance_runtime SET numero = SELECT MAX(numero) FROM seance_runtime;

Ya qu'avec les trigger qu'on peut avoir des tables zombies ? (c'est vieux tout ca )
Je test desuite

re-edit:
Loupé, ca ne fonctionne pas mais je m'en doutais !

Merci,
Nico

[Christophe P.]

En MySQL il n'y a pas de séquence mais il y a l'auto-incrémentation, ce qui correspond au même.

[fr1man]

Oui mais est-ce que cela garantit qu'on ne peut pas avoir deux valeurs identiques en cas d'accès simultané.
Il me semble avoir lu le contraire dans une doc.
A vérifier.

[bumbo500]

Tu peux aussi peut etre regarder du coté des champs timestamp et version qui permettent de gérer la concurrence d'accès.

[Christophe P.]

Oui mais est-ce que cela garantit qu'on ne peut pas avoir deux valeurs identiques en cas d'accès simultané.
Il me semble avoir lu le contraire dans une doc.
A vérifier.

Je n'ai rien vu sur ce problème, mais je ne suis pas un expert MySQL.

[fr1man]

J'ai mélangé avec ceci provenant de la doc hibernate en rapport avec la génération d'id:

Code :

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

1
2
3
 
increment 
Génère des identifiants de type long, short ou int qui ne sont uniques que si aucun autre processus n'insère de données dans la même table. Ne pas utiliser en environnement clusterisé.

Donc j'ai rien dit

[n!co]

En MySQL il n'y a pas de séquence mais il y a l'auto-incrémentation, ce qui correspond au même.

Oui mais est-ce que cela garantit qu'on ne peut pas avoir deux valeurs identiques en cas d'accès simultané.
Il me semble avoir lu le contraire dans une doc.
A vérifier.

Si un vérrou spécial est posé AUTO-INC et assure que chaque utilisateur est une entrée différente même dans deux transactions différentes, ce qui eplique les trous si une transaction est annulée.

Tu peux aussi peut etre regarder du coté des champs timestamp et version qui permettent de gérer la concurrence d'accès.

En faite c'est pas une gestion de la concurence sur l'écriture d'une ligne, mais la concurence sur la lecture d'une ligne.

Il faudrait que je puisse vérouiller en lecture exclusif les lignes que je viens de lire dans ma transaction.

Code :

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

SELECT MAX(numero) FROM seance_runtime GROUP BY seance = ?

Je peux ainsi garantir que personne d'autre ne puisse recupérer le numéro identique.
J'ajoute ma nouvelle ligne et je libère. Une autre personne peux ainsi vérouiller la table et ainsi de suite.
Je ne penses pas que le timestamp ou la version puisse faire cela.

Il pour l'utilisation de l'autoncremente, ca va pas tout a fait car il faut qu'a la prochaine séance, la numérotatyion recommence à 1 !

Je regarde la doc mysql pour voir ce que je pourrais faire en code natif !
Mais j'ai aussi peur qu'hibernate ne suive pas derrière, a mon que je l'oblige de lire l'information en base de données et non pas dans le cache !

Enfin galère quoi, j'ai pas de soluce pour le moment

[n!co]

Que pensez vous de :

Code :

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

LOCK TABLES seance_runtime WRITE

Que va dire hibernate devant ca ?

[n!co]

Je relance le sujet car je n'ai pas trouvé de réelles solutions pour le moment.

Pour être précis j'utilise Hibernate Entity Manager et la seule chose qu'il me permet de faire c'est un LockModeType.READ et LockModeType.WRITE qui n'impacte que l'entité que l'on choisi, le premier pour assurer la lecture coherente et l'autre pour en plus de ca, obliger l'incrementation du numéro de version.
Donc ca ne convient pas a mon problème.

Sinon je pensais faire un lock table avec un requete natif, mais je ne sais pas comment va réagir hibernate
Quelqu'un aurait il une expérience dans ce genre de situation ?

Merci

[n!co]

Bon j'ai trouvé une solution en partant sur une autre voie.

J'ai rajouté une contrainte d'unicité sur mes champs (id_seance, numero).
Comme ca j'ai juste a gérer les erreurs de contrainte et boucler jusqu'a ce que le juge recupère un numéro unique.

C'est finalement plus logique qu'un lock de la table