Sind Stored Procedures atomar?

[goof]

Hallo,

bei der Entwicklung einer Datenbankanwendung bewegt mich gerade die Frage, ob eigentlich Stored Procedures atomar ausgeführt werden d.h. in einem Zug, oder es sein kann, dass zwei Stored Procedures gleichzeitig ausgeführt werden können und sich damit gegenseitig beeinflussen?

Ganz konkret will ich eine Insert-Anweisung in eine SP packen, in der ich zunächst prüfe ob bereits ein Eintrag mit diesen Werten in der Datenbank vorhanden ist, d.h. ich mache eine Select-Anweisung und zähle die zurückgegebenen Einträge. Wenn sie 0 sind folgt im nächsten Schritt eine Insert-Anweisung. Ist es möglich, dass wenn nahezu zwei Personen zeitgleich die Prozedur mit gleichen Werten aufrufen, sie genau nach der Select-Anweisung unterbrochen wird und damit am Ende zwei gleiche Einträge in der Datenbank stehen?

[hwoess]

Theoretisch ist es natürlich möglich. Wenn es jetzt mal nur um doppelte Werte geht, würde ich das die Datenbank alleine machen lassen, indem ich über die Felder, die nicht doppelt sein dürfen, einen eindeutigen Index lege. Damit braucht man vorher nichts zählen und kann auch immer sicher sein, dass man nicht mal mit einer Fremdanwenung oder über das ManagementStudio selber doppelte Daten reinkriegt.
Anwendungen, die da jetzt ein Insert machen, bräuchten nur das insert in einem try/catch-Block ausführen, wenn's okay war braucht man nichts weiter zu tun, im anderen Fall fängt man den Fehler ab und je nachdem was es war (muss nicht unbedingt "doppelter Schlüssel" sein, könnte ja auch sein, dass der Server steht oder Rechte geändert wurden...) macht man im Programm was anderes, signalisiert das dem Anwender, ....

bye,
Helmut

[dimitri]

Ganz konkret will ich eine Insert-Anweisung in eine SP packen, in der ich zunächst prüfe ob bereits ein Eintrag mit diesen Werten in der Datenbank vorhanden ist, d.h. ich mache eine Select-Anweisung und zähle die zurückgegebenen Einträge. Wenn sie 0 sind

Zu dem was hwoess bereits sagte, ist deine Methode auch nicht sicher, denn nicht committete Änderungen einer anderen Session wirst Du nicht sehen, was wiederum zu doppelten Einträgen führen kann.

Daher: Nie Constraints nachprogrammieren!

Dim

[goof]

Vielen Dank für die Hinweise. Meine Frage hatte ich eigentlich gestellt, weil ich ursprünglich vorhatte vollständig auf Transaktionen zu verzichten. Was ja wiederum gehen würde, sofern ich nur eine einzelne und damit atomare Insert-Anweisung benötige.

Kann ich auf einen weiteren Index über die Tabelle legen, welche doppelte Einträge verhindet, aber nicht der Primärschlüssel ist? - Primärschlüssel ist bereits eine ID.

[dimitri]

weil ich ursprünglich vorhatte vollständig auf Transaktionen zu verzichten.

Wie bist denn auf die komische Idee gekommen? Transaktionen sind ein Keyfeature einer jeder vernünftigen Datenbank. Du kannst übrigends Transaktionen nicht ausschalten, maximal ein Autocommit wäre möglich.

Kann ich auf einen weiteren Index über die Tabelle legen, welche doppelte Einträge verhindet, aber nicht der Primärschlüssel ist?

create unique index ...

Dim

[O. Helper]

Hallo goof,

eigentlich Stored Procedures atomar ausgeführt werden

Transaktionen werden atomar ausgeführt (ACID Prinzip).

Wenn die SP in einer Transaktion ausgeführt wird, ist die SP sozusagen "atomar". Zudem legt man selbst noch den Transaction Isolation Level fest.

Ansonsten kommt das von Dimitri erwähnte "AutoCommit" zum tragen

Beispiel als Erklärung (sehr vereinfacht)
- SP 1 mach das Select, es wird ein S-Lock auf die Tabelle angelegt.
- Wenn das Select fertig ist, wird durch AutoCommit des S-Lock wieder entfernt
=> Es können parallel weitere Selects z.B. durch SP 2 auf die Tabelle ausgeführt werden.
- Es erfolgt das INSERT, SP 2 bekommt davon nichts mit.

Also, wenn Du so etwas programmieren willst, dann innerhalb einer Transaktion und überlege Dir, inwie weit die betroffenen Tabellen dazu wie stark gesperrt werden müssen.
!Immer das Deadlock Problem im Hinterkopf behalten!