Voir la source de Concurrence d'accès (code)

===Introduction===
La stratégie de concurrence d’accès influence directement les performances et les capacités du système à supporter la montée en charge.

Dans les systèmes objets il y a généralement deux approches pour aborder le problème de la concurrence d’accès :
*l’approche pessimiste,
*l’approche optimiste.

Dans l’approche pessimiste les objets sont systématiquement verrouillés lorsqu’ils entrent dans une transaction. Les verrous sont gérés de manière à garantir qu’à un instant « t » une seule station puisse modifier un objet donné.

Dans l’approche optimiste les objets ne sont pas verrouillés lorsqu’ils entrent dans une transaction. Lors de la mise à jour le système vérifie qu’ils n’ont pas été modifiés par une autre station entre le moment où ils ont été lus et le moment où ils sont mis à jour. Au cas où un objet a été modifié l’ensemble de la transaction est annulée.

La méthode optimiste ne modifie pas le niveau de concurrence d’accès que peut supporter une application, simplement en général elle est plus efficace car elle économise le coût de la gestion des verrous.

Le framework Ligne 1000 supporte trois modes de concurrence d’accès qui sont paramétrables au niveau de chaque classe :
*Le mode « super optimiste »
:Un objet peut être modifié simultanément par plusieurs stations, c’est la mise à jour de la dernière station qui est conservée, pour les autres stations aucune erreur n’est remontée.
*Le mode optimiste
:Un objet peut être modifié simultanément par plusieurs stations, c’est la mise à jour de la première station qui est conservée, pour les autres stations la transaction est annulée.
*Le mode pessimiste
:Un objet ne peut être modifié que par une seule station.

A la construction d’une classe vous devez définir la stratégie de concurrence d’accès :

{{#images:image1.png|dsm/code/concurrence}}

*Super optimiste
:A la création d’une classe la valeur par défaut est pour une stratégie de concurrence d’accès « super optimiste ». Aucune des cases à cocher Classe à verrouillage pessimiste et Classe à verrouillage optimiste n’est cochée.

*Optimiste
:Pour définir une classe comme classe à verrouillage optimiste vous devez cocher l’option Classe à verrouillage optimiste.
Les classes qui sont définies comme classe à verrouillage optimiste sont celles qui contiennent des donnée sensibles avec une probabilité minimum de se trouver dans un accès concurrentiel.

*Pessimiste
:Pour définir une classe comme classe à verrouillage optimiste vous devez cocher l’option Classe à verrouillage pessimiste.
Les classes qui sont définies comme classe à verrouillage pessimiste sont celles qui contiennent des données sensibles que deux utilisateurs ne doivent pas modifier simultanément.
Verrous mortels

Une conséquence néfaste de la gestion de verrou nécessaire à la gestion pessimiste de la concurrence d’accès est le problème des verrous mortels. Dans certaines configurations deux transactions concurrentes peuvent se bloquer mutuellement en essayant d’obtenir des verrous sur des objets communs aux deux transactions.

{{#images:image2.png|dsm/code/concurrence}}

Dans un système traditionnel on évite les verrous mortels en contrôlant l’ordre de verrouillage des objets ; ceci est inapplicable dans le concept de transaction objet car les objets s’ajoutent aux transactions en cours au fur et à mesure des modifications apportées par le code métier et il est impossible d’en prévoir l’ordre.

Le Framework Ligne 1000 implémente un algorithme déterministe de détection de verrous mortels. Lorsqu’un objet entrant dans une transaction provoque une situation de verrous mortels sa transaction est annulée.

{{info|Le framework ordonne les objets dans les transactions SQL pour limiter les risques de verrous mortel.}}

{{Tip|Un objet pessimiste utilisé dans une transaction longue utilisera automatiquement le mode optimiste {{Version650}}}}

{{Footer|Code métier}}
[[category:Code métier]]