Activation de plusieurs ensembles de résultats actifs (MARS).

MARS (Multiple Active Result Sets) est une fonctionnalité qui opère avec SQL Server pour permettre l’exécution de plusieurs lots sur une seule connexion. Quand MARS est activé pour une utilisation avec SQL Server, chaque objet de commande utilisé ajoute une session à la connexion.

Activation et désactivation de MARS dans la chaîne de connexion

La fonctionnalité MARS est désactivée par défaut. Elle peut être activée en ajoutant la paire de mots clés "MultipleActiveResultSets=True" à votre chaîne de connexion. « True » est la seule valeur valide pour l’activation de MARS. L’exemple suivant montre comment se connecter à une instance de SQL Server et spécifier que MARS doit être activé.

Dim connectionString As String = "..." & _
    "MultipleActiveResultSets=True"

string connectionString = "..." +
    "MultipleActiveResultSets=True";

Vous pouvez désactiver MARS en ajoutant la paire de mots clés "MultipleActiveResultSets=False" à votre chaîne de connexion. « False » est la seule valeur valide pour la désactivation de MARS.

Considérations particulières en relation avec l'utilisation de MARS

En général, les applications existantes ne doivent pas être modifiées pour utiliser une connexion prenant en charge MARS. Toutefois, si vous souhaitez utiliser les fonctionnalités MARS dans vos applications, vous devez comprendre les considérations spéciales suivantes.

Entrelacement d'instructions

Les opérations MARS s’exécutent de façon synchrone sur le serveur. L’imbrication des instructions BULK INSERT et SELECT est autorisée. Toutefois, les instructions DML (Data Manipulation Language) et DDL (Data Definition Language) s’exécutent de manière atomique. Toutes les instructions tentant de s’exécuter pendant l’exécution d’un lot atomique sont bloquées. L’exécution en parallèle au niveau du serveur n’est pas une fonctionnalité MARS.

Si deux lots sont envoyés sous une connexion MARS, l’un d’eux contenant une instruction SELECT, l’autre contenant une instruction DML, la commande DML peut commencer à s’exécuter pendant l’exécution de l’instruction SELECT. Toutefois, l’instruction DML doit s’exécuter jusqu’à l’achèvement avant que l’instruction SELECT puisse progresser. Si les deux instructions s’exécutent sous la même transaction, toutes les modifications apportées par une instruction DML une fois l’instruction SELECT démarrée ne sont pas visibles par l’opération de lecture.

Une WAITFOR instruction à l’intérieur d’une SELECT instruction ne libère pas la transaction pendant qu’elle attend, c’est-à-dire jusqu’à ce que la première ligne soit générée. Cela implique qu’aucun autre lot ne peut s’exécuter dans la même connexion pendant qu’une instruction WAITFOR est en attente.

Cache de session MARS

Lorsqu’une connexion s’ouvre avec MARS activée, le fournisseur crée une session logique, ce qui ajoute une surcharge. Pour réduire cette surcharge, SqlClient met en cache jusqu’à 10 sessions MARS par connexion. La limite n’est pas réglable par l’utilisateur. Si la limite est atteinte, le fournisseur crée une nouvelle session sans générer d’erreur. Le cache et ses sessions ne sont partagés avec aucune autre connexion. Après l’utilisation, une session retourne au cache, sauf si le cache est plein, auquel cas le fournisseur de cache la ferme. Les sessions mises en cache n’expirent pas ; le fournisseur les nettoie lorsque vous libérez la connexion. Le fournisseur remplit le cache à mesure que l’application a besoin de sessions.

Sécurité des threads

Les opérations MARS ne sont pas thread-safe.

Regroupement de connexions

Les connexions compatibles MARS sont regroupées par pool comme n’importe quelle autre connexion. Si une application ouvre deux connexions, l’une avec MARS activée et l’autre avec MARS désactivée, les deux connexions se trouvent dans des pools distincts. Pour plus d’informations, consultez Regroupement de connexions SQL Server (ADO.NET).

Environnement d'exécution par lots SQL Server

Lorsqu’une connexion est ouverte, un environnement par défaut est défini. Cet environnement est ensuite copié dans une session MARS logique.

L’environnement d’exécution par lot comprend les composants suivants :

• Définir des options (par exemple, ANSI_NULLS, DATE_FORMAT, LANGUAGE, TEXTSIZE)

• Contexte de sécurité (rôle d’utilisateur/d’application)

• Contexte de la base de données (base de données actuelle)

• Variables d’état d’exécution (par exemple, @@ERROR, @@ROWCOUNT, @@FETCH_STATUS@@IDENTITY)

• Tables temporaires de niveau supérieur

Avec MARS, un environnement d’exécution par défaut est associé à une connexion. Chaque nouveau traitement dont l’exécution commence sous une connexion donnée reçoit une copie de l’environnement par défaut. Chaque fois que le code est exécuté sous un lot donné, toutes les modifications apportées à l’environnement sont étendues au lot spécifique. Une fois l’exécution achevée, les paramètres d’exécution sont copiés dans l’environnement par défaut. Lorsqu'un lot unique émet plusieurs commandes à exécuter de façon séquentielle sous la même transaction, la sémantique correspond à celle des connexions impliquant des clients ou des serveurs antérieurs.

Exécution en parallèle

MARS n’est pas conçu pour supprimer toutes les exigences de connexions multiples dans une application. Si une application a besoin d’une véritable exécution parallèle des commandes sur un serveur, vous devez utiliser plusieurs connexions.

Par exemple, considérez le scénario suivant. Deux objets de commande sont créés, l’un pour le traitement d’un jeu de résultats et l’autre pour la mise à jour des données ; ils partagent une connexion commune via MARS. Dans ce scénario, Transaction. Commit échoue pendant la mise à jour jusqu’à ce que tous les résultats aient été lus sur le premier objet de commande, et génère l’exception suivante :

Message : Le contexte de transaction est utilisé par une autre session.

Source : Fournisseur de données .NET SqlClient

Attendu : (nul)

Reçu : Microsoft.Data.SqlClient.SqlException

Trois options permettent de prendre en charge ce scénario :

1. Démarrez la transaction après la création du lecteur, afin qu’il ne fasse pas partie de la transaction. Chaque mise à jour devient alors sa propre transaction.

2. Committez tout le travail après la fermeture du lecteur. Cela peut entraîner un lot important de mises à jour.

3. N’utilisez pas MARS ; utilisez plutôt une connexion distincte pour chaque objet de commande comme avant MARS.

Détection de la prise en charge de MARS

Une application peut vérifier la prise en charge de MARS en lisant la valeur SqlConnection.ServerVersion. Le nombre majeur doit être 9 pour SQL Server 2005 et 10 pour SQL Server 2008.

Voir aussi

• MARS (Multiple Active Result Sets)
• Vue d'ensemble d’ADO.NET