[concurrence] un verrou bien farfelu !

Salut,

je suis en train d'étudier la concurrence et pour l'occasion, je dois créer une base de donnée. Seulement, il y a des parties qui me paraissent louches:


Voici d'abord une partie de la donnée:

Citation:

---

Une table peut désormais être verrouillée en lecture ou en écriture par une transaction. Avant d’exécuter n’importe quelle opération de lecture/écriture, le serveur de base de données doit s’assurer de posséder le verrou correspondant. Au besoin, un verrou en lecture pourra ẽtre transformé en un verrou en écriture. Les verrous détenus par une transaction ne sont restitués qu’à la fin de la transaction. L’interblocage sera traité de la façon suivante. Un thread-exécutant qui demande un verrou attend au maximum t secondes.

---

Comme je comprends le problème, on empêche les accès simultannés en lecture (car il y a un verrou), mais peut-être je me trompe (le verrou serait là juste pour contrôler l'écriture).
Mais ce qui me pose vraiment problème, c'est que je ne sais pas comment convertir le verrou de lecture en écriture. Je crois que je ne comprends même pas ce que ça veut dire. Est-ce que ça voudrait dire que lors d'une écriture (s'il n'y a pas de lecture), alors on a 2 verrous à disposition ? Ca pose problème là...

Pour implémenter ça, je pensais utiliser l'interface "ReadWriteLock", il me semble qu'elle correspond vraiment bien à ce cas là, mais vraiment, cette partie sur le verrou qui devient lecture ou écriture au besoin me pose problème.

Merci beaucoup pour votre aide ;)

Un verrou de lecture est generalement un verrou partagé (shared lock). Cela signifie que plusieurs transactions peuvent posseder le verrou au meme moment, et donc elles peuvent toutes acceder en lecture a la table. Cela offre un gain de performance en lecture.

Un verrou d'ecriture est presque toujours exclusif. Une seule transaction peut posseder ce verrou, et elle est donc la seule a pouvoir ecrire dans la table.

Ces deux verrous sont mutuellement exclusifs. Un transaction ne peut pas demander un verrou d'ecriture si une autre transaction possede un verrou de lecture. Et reciproquement.

Generalement, on cree un seul objet verrou qui gere toutes ces regles. Cet objet possede donc 3 methodes:
+ getReadLock()
+ getWriteLock()
+ releaseLock()
avec obligation de faire un releaseLock() pour chaque getXXXLock().

Le changement de type de verrou est une optimisation pour eviter, dans une meme transaction, d'enchainer les operations : getReadLock() -> releaseLock() -> getWriteLock() -> releaseLock().

Dans ce cas, on peut optimiser avec une methode "changeToWriteLock()". L'enchainement devient alors: getReadLock() -> changeToWriteLock() -> releaseLock().

Cette technique offre aussi l'avantage d'etre sur que les données n'ont pas été changée par une autre transaction. En effet, dans le 1er cas, comme on a fait un releaseLock() au milieu, il se peut qu'une autre transaction s'execute et modifie les données que l'on vient de lire.