Svantaggi di MARS (Multiple Active Result Sets)?

Qualcuno sa di eventuali svantaggi di MARS (Multiple Active Result Sets)? Qualcuno sa per quale ragione si dovrebbe evitare di usare MARS, come i casi in cui i cursori sono più utili di MARS.

Ci sono almeno due inconvenienti (potenziali) noti (da questo (1) blog del team ):

  1. Ovviamente questo può causare potenziali problemi per qualsiasi sistema legacy che non è stato progettato per funzionare con un progetto abilitato MARS – “il codice esistente ottimizzato per funzionare nel mondo non MARS potrebbe mostrare un leggero calo di prestazioni quando eseguito non modificato con MARS”

  2. “Con MARS puoi inviare più batch multi-statement al server. Il server interpreterà l’esecuzione di tali batch, il che significa che se i batch cambiano lo stato del server tramite istruzioni SET o USE, ad esempio, o utilizzano istruzioni di gestione delle transazioni TSQL (BEGIN TRAN, COMMIT, ROLLBACK), sia tu che il server puoi confonderlo su quale sia il tuo reale intento. “

Devo ancora provare un design abilitato MARS, ma mi sto avvicinando molto al mio progetto attuale. Abbiamo un piccolo problema con le operazioni di query concorrenti (e talvolta dipendenti) (come il pigro caricamento dei dati di configurazione dallo stesso database in cui è in esecuzione un recordset attivo).

Ci sono ulteriori informazioni sul sito MSDN (2) qui

[(1) http://blogs.msdn.com/sqlnativeclient/archive/2006/09/27/774290.aspx ]
[(2) http://msdn.microsoft.com/en-us/library/ms131686.aspx ]

  • Occorrono più risorse del server rispetto a una connessione alla volta.
  • È necessario eseguire SQL Server 2005 o versioni successive. Quindi questo può essere un problema in ambienti legacy (ack!).

a seconda di cosa? non ci sono veri svantaggi.

non supportano i punti di salvataggio della transazione. ma non penso che questo sia uno svantaggio.