23 octobre 2006

Travailler sans les transactions

Le modèle technique fait qu'il n'y a pas de transactions...

C'est facile à gérer dans le cas des mises à jour, puisqu'il s'agit simplement de poser des verrous applicatifs ou des verrous métier. Rappelons à cette occasion qu'un verrou applicatif ou métier bien posé est une garantie de la cohérence des données, tandis que tous les verrous techniques du monde auront toujours a un moment donné un ou plusieurs angles morts, et là, bien malin qui saura dépatouiller le MPD de la mort, en répondant à la fois aux exigences des fonctionnels qui veulent pouvoir modifier la base de prod' en cas de pépin (si, si) et aux nouvelles contraintes techniques des architectes (si, si).
Par ailleurs dans le modèle la cohérence des données est également assurée par leur versioning : deux parachutes valent mieux qu'un.

Pour les mises à jour des données métier, donc, pas de problème. Pour certaines modifications des données techniques non versionnées (incrémenter une date de mise à jour...), ça passe aussi. Mais que se passe-t-il en cas de destruction des données techniques ? Je ne sais pas, moi, la destruction de la session applicative, par exemple.
Si une session est en train d'être détruite, il faut interdire toute lecture et toute modification sur les objets en base attachés à cette session. Ah, zut, on n'a pas les transactions. Et à ce niveau on n'est plus versionnés...
Bon, dans ce cas particulier, la solution est simple : on s'en sort en préparant un champ de date de dernier accès à la session et en posant un verrou par une requête classique UPDATE WHERE, comme dans le cas applicatif.

Mais voici la conclusion : travailler sans les transactions impose dans certains cas de raffiner son modèle de données (ici en rajoutant un champ, s'il n'était pas prévu au départ), afin de pouvoir poser des verrous par des requêtes simples, seules garanties d'ACIDité.

Une contrainte qui offre en contrepartie à la fois une garantie absolue [ici, la cohérence des données] et une plus grande solidité du modèle, ça ne vous rappelle rien ? Eh oui, les tests.
Pour pouvoir simplement écrire certains tests, il faut parfois revoir, à l'avantage, le modèle.

1 commentaire:

Anonyme a dit…

Personnellement je trouve la solution proposée très proche des redo log des moniteurs transactionnels.

Reste à implémenter les
interruptions de service utilisateur, si l'utilisateur decidait de quitter la fonction et le travail sans transaction
sera finalement devenu un travail avec une transaction gérée par l'applicatif.