SQL Server: Transaction execution always immediately?

Question

Does SQL Server (2005/2008/2012) execute BEGIN TRANSACTION as soon as the command arrives?

Is it - however (option, network buffering/-delay, distributed database, ..) - possible that a BEGIN TRANSACTION command as well as everything following gets held because eg. something else has to happen first?

Further, is there any possibility that - when database/network caused buffering/delay is possible - two transactions will be executed in reverse order?

Answer 1

Yes the transaction will begin as soon as the command arrives and when you do commit or rollback then the operation is done accordingly.

The MSDN doc says:

During query optimization, SQL Server looks for queries or index operations that might benefit from parallel execution. For these queries, SQL Server inserts exchange operators into the query execution plan to prepare the query for parallel execution. An exchange operator is an operator in a query execution plan that provides process management, data redistribution, and flow control. The exchange operator includes the Distribute Streams, Repartition Streams, and Gather Streams logical operators as subtypes, one or more of which can appear in the Showplan output of a query plan for a parallel query.

You can have parallel execution of the queries but once a query gets started until and unless you are not changing the isolation level or if there is any error then you cannot alter the execution of your query. So in short you cannot make the other query wait for the first query getting executed.

Further, is there any possibility that - when database/network caused buffering/delay is possible - two transactions will be executed in reverse order?

As far as I know you cannot change the order of execution of your query which changing the sequence or making any code/query change.

Answer 2

When the server gets the BEGIN TRAN message, it starts reserving resources and executing the commands. If another transaction arrives that needs some of the same resources, it will be required to wait until the first transaction releases those resources, usually with a COMMIT.

This can be altered somewhat by changing the server isolation levels, but in general transactions executed in the order they are received.

There is a chance that network issues could cause transactions to change order if users are making changes from different locations. But once a transaction reaches the server, there is no reason it would reverse order if they are using the same objects.

This behavior is the C in ACID : Consistency.

It is possible that transactions could be executed out of order, but only if they are not accessing the same resources.