9

Inside a stored procedure, I have the following : ( sql server 2008 )

 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION getStuff BEGIN TRY /* some selects, updates, etc, etc. */ .... COMMIT TRANSACTION getStuff END TRY BEGIN CATCH ... END CATCH

Since this is transaction based, my thought was the rest of the database connections will not be affected by the SERIALIZABLE.

Do I need to implicitly set isolation level to read committed after my commit? Will this adversely effect other connections between my application server and database server?

Improve this question

3 Answers 3

Reset to default
6

The command is TRANSACTION ISOLATION LEVEL, not SERVER ISOLATION LEVEL. It only changes the isolation level for the transaction scope.

Improve this answer
5

No you do not have to implicitly set isolation level back to read committed.

From books online.

If you issue SET TRANSACTION ISOLATION LEVEL in a stored procedure or trigger, when the object returns control the isolation level is reset to the level in effect when the object was invoked. For example, if you set REPEATABLE READ in a batch, and the batch then calls a stored procedure that sets the isolation level to SERIALIZABLE, the isolation level setting reverts to REPEATABLE READ when the stored procedure returns control to the batch.

Improve this answer
3

The command that you posted just run the transaction in the SP with TRANSACTION ISOLATION LEVEL SERIALIZABLE. Other connections will default to the default isolation level - read committed (unless specified a different isolation level explicitly).

There is an excellent series by Paul White - SQL Server Isolation Levels : A Series which will help you understand in depth what different isolation levels mean and do when they are used.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.