Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Transactions et verrouillages

Transactions et verrouillages

La gestion des transactions au sens de la base de données est un problème qui dépasse l’ergonomie, mais qui a néanmoins des impacts sur celle-ci.

La question est la suivante : que se passe-t-il lorsqu’un utilisateur commence à modifier une entité ? Cette entité doit-elle être verrouillée pour tous les autres utilisateurs ? Que se passe-t-il si un second utilisateur engage à son tour une modification de la même entité ? Faut-il le prévenir ?

Ce n’est pas tant au plan technique qu’il faut analyser cette question, mais sous l’angle des processus de travail.

Que conviendrait-il de faire si Jean a commencé à modifier le client A et que Marie veut aussi modifier le client A ?

D’abord le cas est-il réellement probable ? Jean et Marie s’occupent-ils des mêmes clients ?

Faisaient-ils la même modification ? Auquel cas, il n’y a pas de problème. Faisaient-ils des modifications incohérentes ? Auquel cas il y a peut-être un problème d’organisation qui n’a rien à voir avec notre application.

Dans tous les cas si deux utilisateurs dans deux bureaux différents entreprennent de modifier le même client, le fait que l’un valide sa transaction avant l’autre est totalement aléatoire, de sorte qu’il n’y a aucune raison de penser que le premier soit à privilégier par rapport au second. Et de même, le timing étant imprévisible, le second utilisateur aurait pu commencer sa transaction juste après la validation du premier. Dans ce cas, il n’y aurait pas eu de conflit mais la seconde modification aurait néanmoins écrasé la première.

D’autre part, souvenons nous que la simplicité fera la fiabilité, qui décidera de l’adhésion des utilisateurs.