[.NET 2.0] Wat wordt gelocked bij Isolation Lvl Serializable

[Verwijderd]

Zelf werk ik hier hoofdzakelijk in een ASP.NET 2.0 omgeving, maar voor deze vraag maakt dat niet zoveel uit denk ik. Op de MSDN pagina met de beschrijving van de IsolationLevel enumeratie, een TransactionOptions property, staat het volgende:

The lowest isolation level, ReadUncommitted, allows many transactions to operate on a data store simultaneously and provides no protection against data corruption due to interruptive transactions. The highest isolation level, Serializable, provides a high degree of protection against interruptive transactions, but requires that each transaction complete before any other transactions are allowed to operate on the data.

Persoonlijk vind ik het wel zo gemakkelijk als het IsolationLevel zo hoog mogelijk staat ingesteld, aangezien je daarmee een hoop vervelende situaties kunt vermijden op drukke websites (met veel INSERTs en UPDATEs naar de database, in dit geval MS SQL Server 2005). Wordt hier echter geschreven dat je "data store"-breed maar één simultane transactie mag hebben op het "Serializable"-niveau? Dat lijkt me namelijk dan weer onnodig restrictief en 'performance-hampering' aangezien ik vrij intensief van transacties gebruik moet maken. Of worden op dit niveau alleen de rows actief vergrendeld, waar de volatiele gegevens in staan?

[Verwijderd]

*subtiel bumpje* (ik bijt niet hoor )

[ Voor 45% gewijzigd door Verwijderd op 07-02-2006 22:33 ]

[Verwijderd]

MSDN
Volgens mij wordt standaard de gehele table gelockt, maar je kunt ook aangeven dat alleen de affected rows gelockt moeten worden door NOLOCK te gebruiken.

[BasSpruit]

Het grote voordeel van Serializable is dat alles wat je doet alleen binnen dezelfde transactie beschikbaar is, en voor elke andere transactie niet. (tot een COMMIT natuurlijk). Dit geeft een maximale bescherming tegen data corruptie.

Het nadeel is echter dat hierdoor het log sterk groeit, en het geheugengebruik + processor tijd sterk toeneemt.

[EfBe]

Verwijderd schreef op maandag 06 februari 2006 @ 22:38:
Zelf werk ik hier hoofdzakelijk in een ASP.NET 2.0 omgeving, maar voor deze vraag maakt dat niet zoveel uit denk ik. Op de MSDN pagina met de beschrijving van de IsolationLevel enumeratie, een TransactionOptions property, staat het volgende:
[...]

Persoonlijk vind ik het wel zo gemakkelijk als het IsolationLevel zo hoog mogelijk staat ingesteld, aangezien je daarmee een hoop vervelende situaties kunt vermijden op drukke websites (met veel INSERTs en UPDATEs naar de database, in dit geval MS SQL Server 2005). Wordt hier echter geschreven dat je "data store"-breed maar één simultane transactie mag hebben op het "Serializable"-niveau? Dat lijkt me namelijk dan weer onnodig restrictief en 'performance-hampering' aangezien ik vrij intensief van transacties gebruik moet maken. Of worden op dit niveau alleen de rows actief vergrendeld, waar de volatiele gegevens in staan?

Isolationlevel gaat over de data IN de transactie. Hoe restrictiever je dat instelt (bv serializable), hoe minder access er is voor andere threads/transactions tot de data die jij aanraakt in je transaction.

Een serializable transaction is eigenlijk alleen nuttig wanneer je bv zelf identity sequences hebt gemaakt met een table en een stored proc. Het nadeel is nl, dat het een range lock zet, dus als een andere thread een row insert in een table die in jouw range valt, die insert geblockt wordt.

In de BOL staat wel info over locking, ik denk dat je dat ook moet doornemen, icm transaction levels, bv welke levels welke locks zetten.

Rule of thumb: Sqlserver de locking laten doen en gewoon readcommitted gebruiken. Het punt is dat sqlserver prima in staat is het zelf te regelen en als je gewone transaction regels hanteert, dus GEEN user interaction, ALLE reads EERST doen, dan de transaction starten en a.s.a.p. committen, je nergens last van hebt.

SqlServer heeft wel als nadeel dat writers readers blocken en omgekeerd, dus heb je een table met een paar miljoen regels en deze wordt veel gelezen EN krijgt veel updates/nieuwe regels, je veel blocking hebt. 2005 heeft een nieuw isolation level, 'snapshot', wat dit oplost maar je zit dan wel tegen een performance dipje aan te kijken (niet veel, dacht ik, maar hij is er wel).

[Verwijderd]

Kijk, daar kan ik wel mee uit de voeten! Bedankt!