Hello, Ralf! Wednesday, February 26, 2014, 4:15:33 PM, you wrote:
RJ> when ending a ReadCommited ReadOnly Transaction and releasing RJ> resources what's considered Best Practice? Commit or Rollback. And RJ> if someone can elaborate and why it would be welcome. simple question. if there were no changes made inside read/write transaction, engine will convert Rollback to Commit, since there are no reason to do silly work. :-) (the engine does this also when there were "not much" changes made before Rollback - it undo changes and makes Commit. Only if there were huge amount of changes, which server can't remember, Rollback becomes Rollback). And, read only readcommitted transaction is committed (or pre-committed) at it's start, so, Rollback or Commit for that transaction are the same, i.e. only freeing transaction handle. >From my point of view, Rollback for read only read committed transaction is a nonsense, in any meaning. RJ> When monitoring the system via the Windows PerformanceCounters i RJ> see writes to the database. In my test environment when having RJ> around 400 Readonly Transactions per second (and nothing else) it RJ> sums up to around 2.5MB per second. start and commit/rollback of any transaction will write at least header page and transaction inventory page (s). The exception is read-only database. RJ> Looking at Mon$Transactions at the same time shows 0 RJ> Page_Writes/Page_Marks. this is about work done inside transaction, not by transaction itself. The burth and death of transaction is being counted by attachment, not by transaction. -- Dmitry Kuzmenko, www.ib-aid.com
