Jag håller på att lägga sista handen vid en asp.net applikation som använder en MSSQL 2000 i botten. Problemet är att det relativt ofta uppstår postlåsningar som blockerar servern. Belastningen på sevren är än så länge mycket låg dessutom så något måste vara mycket fel någonstans.

Ungefär så här ser min arkitektur ut:

I datalagret finns objekt i aggregat (typ: objekt äger andra objekt som äger andra objekt etc) och alla objekt i ett aggregat låter rot-objektet sköta databaskopplingen och transaktionen. När det är dags att spara ett aggregat så anropar man alltså rot-objektet som kopplar upp sig via ett databaslager av klasser (se nedan) och startar en transaktion. Därefter sparas alla obekten i tur och ordning och använder sig av samma transaktion. När allt är klart så "committas" transaktionen i god ordning och om något gårt fel så rullas den tillbaka och så vidare.

Jag har varit mycket noggrann med att alla kopplingar stängs som de ska och jag hittar inga misstänkta fall av ohanterade fel som skulle kunna leda till ofärdiga transaktioner.

För att uppnå en låg grad av teknikberoende så används ett separat "databaslager" som hanterar alla uppkopplingar i form av en "pool". Databaslagret räknar referenser till varje uppkoppling och hanterar situationer där antalet uppkopplingar blir för stort.

Förutom eventuella fel i min kod (vilket jag alltså inte har kunnat hitta) så är frågan: Finns det några särskilda hänsyn eller konfigurationer av MSSQL 2K jag kan ha missat? Efter att ha letat runt på internet efter mer info i saken så ser jag att många tycker att man ska explicit ska bestämma låsmekanismen genom att sätta ROWLOCk eller NOLOCK där det är tillämpligt.

Synpunkter / tips?

<Förutom eventuella fel i min kod (vilket jag alltså inte har kunnat hitta) så är frågan:
<Finns det några särskilda hänsyn eller konfigurationer av MSSQL 2K jag kan ha missat?

Nej, inte egentligen.

<Efter att ha letat runt på internet efter mer info i saken så ser jag att många tycker
<att man ska explicit ska bestämma låsmekanismen genom att
<sätta ROWLOCk eller NOLOCK där det är tillämpligt.

Absolut inte!!! SQL Server sätter radlås där det är lämpligt. Om SQL Vill sätta någon annan typ av lås, har den goda skäl för det. Om du anser att den gör "fel" skall du nog istället rapportera det som en bugg.
NOLOCK kan man sätta om man inte vill att SQL skall låsa en läsning. Det gör man om det inte spelar någon roll om datat man får tillbaks är korrupt/inkonsekvent - och när vill man ha korrupt data?

Mit bästa tips: Kolla igenom dina transaktioner igen. Det verkar ju som om objekten dör utan att ha committat.

/micke

Jo din slutsats är deprimerande nog den enda rimliga skulle jag tro. Min applikation är av den naturen att 95% eller mer är "read only" och där använder jag genomgående NOLOCK, inte bara för att undvika låsningar utan även för prestandans skull; detta för att det inte är kritiskt, eller ens sannolikt, att data-korruption skulle kunna uppstå p g a halvfärdiga transaktioner.

Tillbaka till koden då alltså...

Nja, jag förstår ditt resonemang, men du saknar en liten bit.

Du uppdaterar priset på 10 produkter i en transaktion.
Detta låser alla produkter tills transaktionen är klar.
Allt är frid och fröjd. Ingen kan läsa förrän transaktionen är klar.

Låt oss nu säga att du läser ut en prislista precis när halva uppdateringen har gått.

Vanlig SELECT: Läsningen väntar tills transaktionen är klar. Alla priser är riktiga.

NOLOCK: Du får läsa allt rakt av. Du får 5 ändrade priser och 5 o-ändrade. Du kan inte se vilka som är ändrade och inte, nästa gång du läser blir det inte likadant. Det är vad jag menar med inkonsekvent data. Du kan alltså få med en halv ändring. Osannolikt, men sannolikheten ökar med belastningen på servern!

/micke