Reputation:
I am working on a custom application that allows users to insert / update / delete / retrieve data from a database.
Stored procedures I use affects a few tables so I use a transaction and I want to be able to lock these tables to prevent unintended things from happening when multiple users are inserting , deleting, updating, or retrieving (CRUD) data.
My question is what would be the best isolation level to use here, I have read the MSDN on isolation levels and tried to make sense of it as well as searching around, If someone who has been here done that could comment quickly that would be greatly appreciated.
Upvotes: 2
Views: 1377
Reputation: 13551
The default .Net transaction level is serializable. Why do you need another transaction level? Are you under the impression that without an explicit transaction, other connections will be able to change the data out from under you? If so, that is incorrect -- all actions take place in an explicit or implicit transaction, and the only time you can get inconsistent results is if you explicitly set the transaction isolation level to something which allows it.
Edit: As pointed out in a comment, the default for the database engine is READ COMMITTED, but the default for the .Net transactions/connections is SERIALIZABLE, with a caveat -- if the transaction level is changed, it will not be "dropped" for a pooled connection. This means that you can never be absolutely sure what it is unless you set it yourslf. For most cases, you can probably get away with assuming SERIALIZABLE and leave it at that.
Upvotes: 1