There was a newsgroup discussion recently about the intricacies of Multiple Active Resultsets in SQL Server 2005, and one of the questions that came up was "Who actually needs/uses MARS anyway"? I've been taking a much closer look at ADO.NET vNext lately, one reason being that I'm doing a talk on it at TechEd Hong Kong the week after next. Guess what? Both the supplied ObjectServices and LINQ for Entities samples have "multipleactiveresultsets=true" in their connection strings. Why? Without taking MARS out and seeing where the samples fail (I'll get around to it…), I'd bet they use both the "multiple resultsets on the same connection" and "issue an UPDATE statement while reading a rowset on the same connection" patterns. That's what MARS is supposed to address (the very precise ODBC error message for this is "Statement in Use").
BTW, MARS has some interesting effects on transactions and session settings, too. I'll be doing a talk on this at TechEd Europe in Barcelona in Novemeber. Don't forget to stop by and say hi if you're at either of these excellent events.
3 thoughts on “Who uses MARS? ADO.NET vNext, that’s who.”
MARS would allow you update while you still have an open rowset on the same connection. You would update a row after you’d read it, rather than before. So read1, read2, update1, read3 (while keeping the rowset open for related column-or-row lazy reads). But with entities over rowsets/related rowsets. They would use optimistic concurrency to ensure you don’t overwrite someone else’s change that happened between read1 and update1, as always.
Bob, updates –sure. But I assumed that the coolest use will be what Joe Duffy just wrote about — PLINQ (parallel linq):
So wouldn’t such an update block a read? And if so, how do you guarantee if what you are reading was pre-update or post-update? (u can’t guarantee right?)
Comments are closed.