SqlTransaction IsolationLevel

re 1)

Afhænger af:
  a) databasens locking mekanisme
  b) transaction islation level

re a)

database locking = disaster
table locking = disaster
page locking = not good
row locking = great

re b)

jo lavere transaction isolation level ho bedre performance

re 2)

har du behov for et højt transaction isolation level ?

(lyder ikke sådan)

SQLServer kan lave row locking i nyere versioner.

Jeg har sql server 2000

arne_v, kan du uddybe nogle af de ting du skriver om?

Det jeg oensker er at folk kan laese samtidig som jeg insaetter i tabellen, selvom jeg er lang tid om indsaettelsen/opdateringen

eftersom jeg bruger mssql saa har jeg laest foelgende:

http://www.databasejournal.com/features/mssql/article.php/1442301

Det skriver om default:

It ensures that a physically corrupt data will not be read and will never read data that another application has changed and not yet committed

Medfoerer dette at den laaser row, tabel eller page hvori der bliver indsat.

Nyere SQLServer kan som sagt lave row locking.

Jeg tror slet ikke at du har et problem med transaction isolation level.

Der er vel ikke andre transaktioner der vil læse den record du er ved at indsætte ?

Jeg kan godt lide beskrivelsen her:
  http://www.iona.com/support/docs/e2a/asp/5.0/j2ee/DevelopGuide/html/Jta-Bas5.html?test=yes

(ignorer det nederste J2EE specifikke)

Eller er der noget i "faa path tilbage" som kan give samtidigheds problemer ?

Faktisk var den beskrivelse jeg gav her kun et eks. af hvad der mit problem. Lad mig forklare det virkelige eks.:

Parts tabel:
Hver raekke indeholder en beskrivelse af en part som skal laves. Til at starte med er der ingen geometri tilknyttet til raekken men det vil der komme.

Geometries tabel:
Hver raekke indeholder en beskrivelse af en geometri som er fysisk gemt paa en FTP server.

Der sidder 10 mennesker (ligesom paa en samlebaandsfabrik) der via et clientprogram trykker, getNextPart. De faar saa en part fra tabel Parts som ikke har faaet en geometri tilknyttet endnu.

Naar der tilknyttes en geometri, saa sker der foelgende:

1) Der indsaettes en geometri i tabellen Geometries vha en SP. Denne SP kigger om geometrien allerede eksisterer i tabellen Geometries og om denne fundne geometri er tilknyttet nogle parts i tabellen Parts. Tilsidst giver SP'en en path tilbage.
2) Selve geometrien uploades nu til den returneret path via FTP.
3) Tilsidst tilknyttes geometrien (vha relation mellem Geometries og Parts) til en raekke i Parts.

Imellemtiden imens dette sker (indsaettelse af geometrien) saa kan der godt vaere en bruger trykker getNextPart. Denne funktion kigger i tabel Parts efter en raekke uden geometri. Men allerede i 1) selecter jeg jo fra tabel Parts.... Locker jeg saa ikke Parts tabellen, og derved skal GetNextPart vente paa at geometrien er uploadet hvilket tager laaang tid?

Med repeatable read og serializable vil der laves en lock som forhindrer ændring
på rækker som er SELECT'et tidligere.

Men det er kun hvis du vil opdatere den række at du har behov for så højt et
isolation level.

jeg har ikke lige haft tid til at kigge paa det, men kigger paa ASAP.

arne_v>> svar=>point

svar