Sorry, I don't know of a resource off hand.
For optimistic concurrency, the main difficulty is in verifying that nothing
has changed between the time that the procedure starts and the time that the
transaction is ready to be applied. You need to obtain the maximum
rowversions from the set of rows from each table that used in the
calculations, and you also need to know how many source rows were used from
each table. Any change that modifies or adds an interesting row will cause
the maximum rowversion to increase. Thus if the maximum rowversion is
different, that means that an insert or update occurred, or that the row
with the maximum rowversion was deleted. To detect deletes within a range
or rows, you use the count. If fewer rows exist, then a delete occurred.
Some people use WITH(NOLOCK) before the transaction, but I prefer WITH(READ
COMMITTED) instead, because you don't have to worry about another
transaction rolling back between the time that the procedure starts and the
time that the transaction is ready to be applied. In addition, strange
errors can occur if the row that is currently being read WITH(NOLOCK) is
changed between the index seek and the reading of the row.
[quoted text, click to view] "Kevin Yu" <koo9@hotmail.com> wrote in message
news:u9h9R4EHGHA.532@TK2MSFTNGP15.phx.gbl...
>
> "Brian Selzer" <brian@selzer-software.com> wrote in message
> news:Oe349G$GGHA.1192@TK2MSFTNGP11.phx.gbl...
>> There really isn't any difference. (See BEGIN DISTRIBUTED TRANSACTION in
>> BOL.) I contend, however, that transaction control should usually be
>> handled inside stored procedures.
>>
>> Transactions should be as short as possible; therefore, you should wait
>> until the last possible instant before starting a transaction, and you
>> should commit as soon as possible. Cursors and long-running calculations
>> should be avoided within transactions. I use optimistic concurrency
>> control whenever possible, and use rowversions to determine whether a
>> collision has occurred.
>
> is there any resource on the net that I can have a complete comparision of
> all those
> concurrency control and how they are done?
>
> thx Brian
>
>
>
> For most applications, the overall impact on performance of
>> resubmitting a tiny percentage of transactions due to collisions is
>> infinitely smaller than the impact of the additional blocking and the
>> increased probability of deadlocks that are inherent in pessimistic
>> concurrency control.
>>
>> Obviously, starting a transaction on the connection makes it much more
>> difficult to minimize the duration of a transaction.
>>
>>
>>
>> "Kevin Yu" <koo9@hotmail.com> wrote in message
>> news:O4$ou6%23GGHA.3828@TK2MSFTNGP10.phx.gbl...
>>> hi all,
>>>
>>> got a question, what's the different of .NET transaction ( using
>>> connection transaction ) and the transaction inside a store procedure?
>>>
>>> which is faster? does .net transaction use DTC? or both use DTC?
>>>
>>>
>>> thx
>>>
>>> Kevin
>>>
>>>
>>>
>>
>>
>
>
