Disadvantages of MARS (Multiple Active Result Sets)?
Does anyone know of any disadvantages of MARS (Multiple Active Result Sets)? Does anyone know of any reason why one should avoid using MARS, like cases where cursors are more useful then MARS.
Solution 1:
There are apparently at least two known (potential) drawbacks (from this (1) Team blog):
-
Obviously this can cause potential problems for any legacy systems which weren't designed to run against a MARS enabled design - "existing code optimized to run in the non-MARS world may show a slight performance dip when run un-modified with MARS"
-
“With MARS you can send multiple multi-statement batches to the server. The server will interleave execution of such batches, which means that if the batches change server state via SET or USE statements, for example, or use TSQL transaction management statements (BEGIN TRAN, COMMIT, ROLLBACK), both you and the server can get confused about what your actual intent is.”
I've yet to try out a MARS enabled design, but I'm coming very close to doing so on my current project. We have a slight issue with competing (and sometimes dependent) query operations (like lazy loading configuration data out of the same database that an active recordset is executing).
There's more information on the MSDN site (2) here
[ (1) https://web.archive.org/web/20190911155929/https://blogs.msdn.microsoft.com/sqlnativeclient/2006/09/27/using-mars-with-sql-native-client/ ]
[ (2) http://msdn.microsoft.com/en-us/library/ms131686.aspx ]
Solution 2:
- It takes slightly more server resources than doing one connection at a time.
- You have to be running SQL Server 2005 or later. So that can be a problem in legacy (ack!) environments.