Laden...

Threadsafe Stored Procedures

Erstellt von mosspower vor 14 Jahren Letzter Beitrag vor 14 Jahren 1.470 Views
mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren
Threadsafe Stored Procedures

verwendetes Datenbanksystem: SQL Server ≥ 2005

Hallo "Kollegen",

sind SPs threadsafe? Hintergrund ist, dass wir hier eine SP haben, die Sequences hochzählt, also IDs generiert, die gegenwärtig nur von einem Programm (also ein Thread) benutzt wird.

Ich wollte da jetzt mit Threads drübergehen und bin mir nicht sicher ob das gehen kann, denn ich gehe davon aus, dass verschiedene (intern im SQL-Server) Instanzen bei verschiedenen Zugriffen über Threads laufen - bin mir hier aber nicht sicher, deshalb die Frage hier.

Wie macht ihr das mit Sequences, wie es sie in Oracle gibt? Über Trigger?

Gruß und Danke schon einmal im Voraus für etwaige Antworten.

34 Beiträge seit 2009
vor 14 Jahren

Hallo mosspower,

deine Stored Procedures kannst du in so vielen Thread oder Unterschiedlichen Clients wie du willst gleichzeitig ausführen, weil Sequencen grundsätzlich threadsicher sind.
D. h. die Datenbank kümmert sich darum dass ein ID nur einmal vergeben wird.

F
10.010 Beiträge seit 2004
vor 14 Jahren

Das ist nur richtig, bei Datenbanken die Seqenzen von haus aus unterstützen.

MSSQL unterstützt noch keine Sequenzen.

34 Beiträge seit 2009
vor 14 Jahren

OK, das habe ich wohl verdrängt.

Wenn es von Hause aus keine Seq. gibt, dann kann man wenn es sich um ein und dieselbe Tabelle handelt, in der die ID benutzt wird ein Autoincrement feld benutzen.

Wenn das nicht geht, kann man sich ein Tabel bauen wo der letzte benutzen Wert drin steht. Wenn ich jetzt eine neue Nummer benötige, mache ich ein Update auf die Zeile.


  update TABLE set ATTRIBUTE = ATTRIBUTE + 1 where ...

Jetzt ist die Zeile exclusiv für mich gesperrt. Nun den Wert per select auslesen und das commit nicht vergessen.
Wichtig ist hierbei, dass das Isolationlevel korrekt gesetzt ist.

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Danke erst mal für eure Antworten.

Gegenwärtig ist es so implementiert, dass die letzte ID inkrementiert wird und dann ein Update ausgeführt wird, so wie ashinger beschrieben.

Meine Frage lautet nun, wenn mehrere Threads gleichzeitig darauf zugreifen, ob es threadsafe ist, denn, bei z.B. zwei Threads können ja beide einen Select auf die Datenbank machen ohne das einer der beiden Threads schon beim Update war, also nach dem select wechselt der Thread und dann haben beide die aktuelle Zahl und bei beiden wird eins hochgezählt, was ja falsch ist, da dann beide die nächste Zahl haben.

Zumindest denke ich, dass es so ist. Wenn mir aber jemand sagt, dass man SPs synchronizieren kann (bzw. von Haus aus synchronisiert sind), dann wäre mir geholfen.

Ggf. müssten wir das dann auf autoincrement umstellen - damit sollten wir in der Tat keine Probleme haben.

34 Beiträge seit 2009
vor 14 Jahren

Der Trick ist, das du **erst ** das update machen musst.
Und du mache **niemals ** ein select max(ID) from TABLE und diesen wert da um 1 erhöhen. Dann lieber in einer extra Tabelle.

F
10.010 Beiträge seit 2004
vor 14 Jahren

@mosspower:
Warum kein identity?

1.564 Beiträge seit 2007
vor 14 Jahren

Hi

Wie FZelle schon fragt, warum keine IDENTITY?

Zur Verwendung von ID-Tabellen:

Man sollte da immer darauf achten dass man sich nicht immer nur eine einzige ID holt sondern gleich einen Range von IDs reserviert. Die Menge ist dabei oft vom Client-Programm abhängig.

Holt man sich immer nur eine einzige ID, so wird die ID-Tabelle schnell zum Flaschenhals des gesamten Systems da sich alle um diese eine Tabelle und die enthaltenen Werte schlagen.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.