Etude exploratoire de Linq - CoDE - de l'Université libre de Bruxelles

sur des données (typiquement demande de lecture d’une donnée en cours de modification ou à
modifier), les transactions (avec mécanismes de roll-back si satisfaire la transaction s’avère
impossible) et la gestion des exceptions Sql [12]. Dans ces trois domaines, la presque totalité des
problèmes pouvant survenir sont découverts à l’exécution, ce qui est toujours gênant lorsqu’on
souhaite offrir un accès en ligne aux ressources. Linq manipule les objets entités en mémoire et donc
crée un délai supplémentaire durant lequel des accès concurrentiels peuvent apparaître. Un objet
entité contient plusieurs indicateurs permettant de savoir s’il correspond ou non à son homologue en
base de données et le DataContext peut donc détecter lorsqu’un conflit survient. Il est possible
d’assigner une politique de gestion de conflits plus ou moins fine selon ce qui est désiré. Nous
n’allons pas trop nous étendre là-dessus, les heuristiques de résolution de tels conflits dépassent
largement le cadre de ce travail. Nous nous contenterons de dire que les opérations concourantes
ont été envisagées et que le DataContext est en mesure de réaliser une gestion de conflits assez
performantes pour peu qu’une politique adaptée lui soit fournie. Les informations de
synchronisations jouent également un rôle important à ce niveau. En effet, lorsque le comportement
est laissé par défaut (il s’agit du IsDbGenerated), le DataContext ira régulièrement s’informer auprès
de la base de données pour s’enquérir d’éventuels changements survenus pour chaque attribut
ayant ce comportement. Le comportement inverse est également possible. Lorsqu’une entité doit
modifier l’une de ses propriétés, elle en avertit le DataContext et celui-ci va marquer l’entité avec le
statut « modifié » le temps de répercuter les changements dans la base de données. Cela nous laisse
déjà entrevoir les possibilités de conflits engendrés par des opérations concourantes. Microsoft, par
le biais de la bibliothèque en ligne MSDN [4], propose plusieurs politiques de gestion de conflits mais,
comme dit plus haut, tout cela dépasse le cadre de notre étude.
Les transactions sont utilisées systématiquement par les objets de type DataContext. Cela n’a rien
d’étrange quand nous avons vu que le DataContext est l’unique lien entre la base de données et
l’ensemble des entités qui lui sont associées. Lorsque le DataContext se voit soumettre une ou
plusieurs requêtes, il effectue en priorité les changements sur les entités en mémoire et va, selon la
disponibilité de la connexion à la base de données, soumettre à son tour les changements à la base
de données. Chaque requête soumise au DataContext est encapsulée dans une transaction au sens
relationnel du terme. Il est néanmoins possible pour le programmeur d’élargir une transaction, en y
ajoutant des modifications. La classe TransactionScope (disponible dans la bibliothèque
System.Transactions) permet cette opération le plus naturellement qui soit [4]. Il suffit d’instancier
un nouvel objet TransactionScope sans paramètre et d’y inclure l’ensemble des opérations
souhaitées, comme le montre le morceau de code suivant :
using (TransactionScope ts = new TransactionScope())
{
monDataContext.SubmitChanges();
//Soumission de l'ensemble des requêtes en attente
}
//... code supplémentaire éventuel
ts.Complete();
Nous avons encore à aborder le problème des exceptions. Les auteurs de « Programming Linq » [1]
nous présentent trois sources principales d’exceptions, la création d’un DataContext, les accès à une
base données en lecture et ceux en écriture. Notons que Linq ne possède pas d’exceptions qui lui