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