Discussion :

[rt15]

Salut,

Je travaille sur un programme pouvant tourner sur n machines mais travaillant sur la même base (Disons une MySQL ou une Oracle).
Mais il faut que je sois sûr que certaines opération ne soient réalisées que par un seul programme en même temps.
Donc il me faudrait un genre de lock/mutex/semaphore, bref un truc qui permette de m'assurer qu'un seul de mes programmes fait un truc précis à ce moment là.
Attention, une "infinité" de type d'opération doit être permise, et on ne les connait pas toutes à l'avance.
Il y a aussi une potentielle "infinité" de programme et ils n'ont pas d'identifiant.
De plus il faut absolument éviter les deadlocks en cas de crash de l'application.
Le mécanisme "programme qui tombe" -> "connection qui tombe" -> "lock qui tombe" semble donc être la seule solution. D'où l'utilisation d'un "select for update".
Le niveau d'isolation de transaction est fixé à TRANSACTION_READ_COMMITTED.

Je cherche à pouvoir faire ce genre de code :

Code java :

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

1
2
3
4
5
6
7
8
9
10
DatabaseLock lock = lockManager.createLock("Operation A");
lockManager.lock(lock);
try
{
  // Je suis sûr qu'un seul de mes programme peut être ici à un instant t.
}
finally
{
  lockManager.unlock(lock);
}

Ma solution actuelle ressemble au code suivant (Code à la main histoire d'avoir une vague idée, manque des traitements d'erreurs...), avec une table lock_table disposant d'une colonne name avec une clé primaire dessus :

Code java :

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
public class LockManager
{
public DatabaseLock createLock(String name)
{
  return new DatabaseLock(name);
}
 
public void lock(DatabaseLock lock)
{
  Connection connection = new Connection();
  try
  {
    connection.execute("insert into lock_table values (" + lock.getName() + ")");*
  }
  catch (SQLException e)
  {
     // Si l'exception est une duplication de clé primaire, on ignore.
  }
  connection.commit();
 
  // A ce stade, devrait y avoir une ligne. On fait un select for update dessus.
  connection.execute("select name from lock_table where name = " + lock.getName() + " for update");
  lock.setConnection(connection);
}
 
public void unlock(DatabaseLock lock)
{
  Connection connection = lock.getConnection();
  connection.execute("delete from lock_table where name = " + lock.getName());
  // Libère le lock du select for update et supprime la ligne en même temps.
  connection.commit();
  connection.close();
}
}

Dans les faits cela ne fonctionne pas assez bien.
Par exemple, un premier programme peut insérer la ligne et la commiter. Un deuxième peut essayer de faire pareil, et utiliser la ligne du premier pour faire le select for update. Il va finalement supprimer la ligne alors que le premier thread va chercher à faire un select for update dessus.
De plus avoir un select/delete et un insert de la même ligne dans des transactions différentes semble générer des problèmes de deadlock ou la base ne sait plus quelle transaction devrait avoir raison au final...

Bref, c'est loin d'être stable et propre.

Pourtant dans la théorie ce type d'algo (Lock au niveau de la base) semble super pratique et généraliste, mais je ne trouve pas de solution.

Quelqu'un a des idées ?

[tchize_]

d'abord pour isoler tes transaction, il vaut mieux préférer une isolation de type serializable dans ton cas, ca garanti que l'ordre de tes nobmreuses opération n'affectera pas le résultat.

Pour les deadlock, il faut toujours prendre tes locks dans un ordre précis. Si la transaction 1 demande A puis B et que la transaction 2 demande B puis A, t'es dans une situation de deadlock potentiel.
Si tu ne sais pas ordonner tes verrous, alors il est préférable de viser des gestionnaires de base de donnée détectant les deadlock et capable des les réparer en rollbackant une transaction.

Enfin, personellement, je déteste les tables de verrous, ca m'a toujours l'air d'emplatre pour éviter de faire simplement correctement ses select et ses update Mettre volontairement des verrou, c'est brider volontairement une base de données là ou une transaction serializable peut à elle seule donner des garanties d'intégrité. Ou alors tu veux verrouiller dans la table pour faire des opération hors db (email, gestion de fichiers, que sais-je)

[rt15]

Merci pour cette réponse. Effectivement c'est assez pénible à mettre en place et potentiellement source de gros problèmes... Mais dans notre cas, on a pas trop le choix, on ne fait pas que des insert/update.

Je vais donc regarder du côté de TRANSACTION_SERIALIZABLE comme tu le propose.

[tchize_]

tu peux donner un exemple de ce que vous faites d'autre?

[rt15]

Surtout du create table, de l'alter table... Rien qui soit extérieur à la base de données genre fichiers ou mails.

[tchize_]

create table / alter table, c'est du DDL, c'est hors transaction de toutes façon. Tes verrous ne servirons à rien. Par exemple, sous oracle, faire une opération DDL au milieu d'une transaction commite implicitement cette transaction avant le DDL et recommence une nouvelle transaction après. Donc tous tes verrous dans la DB vont être libérés.

Et la doc de mysql mentionne aussi explicitement le même comportement.