Matrice requête × état de la clé
A (Acquisition)
| État de la clé | Action du serveur | Réponse | Moment |
|---|---|---|---|
| Non enregistrée | Enregistre (expiration = maintenant+lease), émet un jeton | A+token+owner+key | Immédiatement |
| Enregistrée + expirée | Renouvelle (maintenant+lease), nouveau jeton | A+token+owner+key | Immédiatement |
Enregistrée + holder valide + wait=0 | Ne pas mettre en file | T+owner+key | Immédiat |
Enregistrée + holder valide + wait>0 | Mettre en file, réponse suspendue | A ou T+owner+key | Acquisition par release/expiry, ou T à la fin de wait |
| File ou capacité serveur au plafond | Ne pas mettre en file | B+owner+key | Immédiat |
- Le chemin de libération est équitable en FIFO : quand le détenteur fait
R, la clé est remise directement à l'attendant en tête de file (sans nouvelle mise en concurrence, avec un nouveau jeton). - Seul le chemin d'expiration n'est pas FIFO.
- Un
owneridentique à celui du holder courant ne reçoit aucun traitement spécial. Il n'autorise ni le retour d'un active token ni le renouvellement du bail ; les règles ordinaires d'une clé détenue s'appliquent. - Les réponses pouvant être désordonnées, le client les associe par
ownerrenvoyé.R(Libération)
| État de la clé | Action du serveur | Réponse |
|---|---|---|
| Enregistrée + jeton concordant, avec attendants | Remise directe à l'attendant en tête de file (nouveau jeton) | R+token+key |
| Enregistrée + jeton concordant, sans attendant | Suppression de la clé | R+token+key |
| Enregistrée + jeton non concordant | Aucune (le verrou est conservé) | N+token+key |
| Non enregistrée | Aucune | N+token+key |
Moment du traitement de l'expiration
- Le mode simple traite l'expiration de façon paresseuse (lazy) — une clé passée son expiration est reprise sur place par la prochaine acquisition (deuxième ligne du tableau ci-dessus), et un balayage séparé toutes les 5 secondes nettoie les clés expirées sans attendant. Une libération sur une clé expirée mais pas encore nettoyée peut donc recevoir
Rplutôt queN. - En mode cluster, le leader attend la prochaine échéance d'un deadline min-heap validant le token, puis commit la commande
Expirepar consensus avant la disparition de la clé. Les écarts d'horloge ne divisent ainsi pas l'état du verrou.