Inconvénients de MARS (Multiple Active Result Sets)?
Quelqu'un connaît-il les inconvénients des MARS (Multiple Active Result Sets)? Quelqu'un sait-il pourquoi il faut éviter d'utiliser MARS, comme les cas où les curseurs sont plus utiles que MARS?.
Il y a apparemment au moins deux inconvénients (potentiels) connus (d'après ceci (1) Blog d'équipe ):
Évidemment, cela peut entraîner des problèmes potentiels pour tous les systèmes hérités qui n'ont pas été conçus pour fonctionner avec une conception compatible MARS - "le code existant optimisé pour fonctionner dans le monde non-MARS peut montrer une légère baisse des performances lorsqu'il est exécuté sans modification avec MARS "
"Avec MARS, vous pouvez envoyer plusieurs lots d'instructions multiples au serveur. Le serveur entrelacera l'exécution de ces lots, ce qui signifie que si les lots changent l'état du serveur via des instructions SET ou USE, par exemple, ou utilisent des instructions de gestion de transactions TSQL (BEGIN TRAN, COMMIT, ROLLBACK), vous et le serveur pouvez être confus quelle est votre intention réelle. "
Je n'ai pas encore essayé une conception compatible MARS, mais j'en suis très proche sur mon projet actuel. Nous avons un léger problème avec les opérations de requête concurrentes (et parfois dépendantes) (comme le chargement paresseux des données de configuration à partir de la même base de données qu'un jeu d'enregistrements actif exécute).
Il y a plus d'informations sur le site MSDN (2) ici
[(1) http://blogs.msdn.com/sqlnativeclient/archive/2006/09/27/774290.aspx ]
[(2) http://msdn.Microsoft.com/en-us/library/ms131686.aspx ]
- Cela prend un peu plus de ressources serveur que d'établir une connexion à la fois.
- Vous devez exécuter SQL Server 2005 ou une version ultérieure. Cela peut donc être un problème dans les environnements hérités (ack!).
selon quoi? il n'y a pas de réels inconvénients.
ils ne prennent pas en charge les points de sauvegarde de transaction. mais je ne pense pas que ce soit un inconvénient.