Tweet
Hallo,
ich habe folgende Situation.
Die Mitarbeiter haben auf einer internen Webseite einen Knopf, z.b. mit dem Namen "Nächste offene Datensatz".
Dabei soll anhand einer Priorisierung ein Datensatz zur Bearbeitung herausgesucht werden.
Ich habe dafür eine vorberechnete Priotabelle z.B.: "Datensatzpriorität". In dieser Tabelle steht nur die DatensatzID, um die es geht eine Priorität und der Mitarbeiter, der gerade daran arbeitet.
Es gibt rund 20-30 Mitarbeiter, die dann den ganzen Tag sich einen neuen Datensatz zur Bearbeitung geben lassen und dann wird dieser bearbeitet.
Ich sage also z.B: "
DECLARE @Datensatz AS Integer
SELECT TOP 1 @Datensatz = Datensatz FROM Priodatensaetze WHERE InBearbeitung = 0 ORDER BY Prioritaet
UPDATE Priodatensaetze SET InBearbeitung = 1 WHERE Datensatz = @Datensatz
SELECT @Datensatz
" (nur Beispiel, das ganze ist dann noch mit ein paar Joins und mehr Spalten).
Ich muss aber nun irgendwie verhindern, dass wenn 2 oder 3 Mitarbeiter wirklcih mal zur ziemlich identischen Zeit auf den "Nächste offene Datensatz" klicken, dass 2 Mitarbeiter den gleichen Datensatz erhalten.
Klar, ich könnte jetzt in meinem .NET Projekt eine Art Warteschlangensystem aufbauen, was die Datensätze abruft und ausgibt. Diesen Weg wollte ich aber eigentlich vermeiden, da die Abfrage doch recht winzig gegen die Datenbank ist.
Gibt es irgendwie rein SQL mäßig die Möglichkeit, dass niemals 2 gleichzeitige Zugriffe den gleichen Datensatz erhalten, sondern einer nach dem anderen? Die Reihenfolge ist dabei vollkommen egal. Mit einer Art Lock oder sowas? Evtl. tritt der Fall produktiv ja auch niemals auf, da die gesamte Abfrage nur 0,5-1 Sekunden dauern wird. Aber ich habe Angst, dass es doch mal passiert, falls z.b. mal auf einer der Tabelle, die gejoint werden, z.b. Locks sind, auf die gewartet wird und dadurch die Abfrage doch ein paar Sekunden länger dauert.
Die gleichzeitige Bearbeitung des selben Datensatzes wäre fatal, da hier bei der Bearbeitung mehr passiert, als nur ein paar Daten zu überarbeiten.
Aktuell ist noch der SQL Server 2012 im Einsatz.
ich habe folgende Situation.
Die Mitarbeiter haben auf einer internen Webseite einen Knopf, z.b. mit dem Namen "Nächste offene Datensatz".
Dabei soll anhand einer Priorisierung ein Datensatz zur Bearbeitung herausgesucht werden.
Ich habe dafür eine vorberechnete Priotabelle z.B.: "Datensatzpriorität". In dieser Tabelle steht nur die DatensatzID, um die es geht eine Priorität und der Mitarbeiter, der gerade daran arbeitet.
Es gibt rund 20-30 Mitarbeiter, die dann den ganzen Tag sich einen neuen Datensatz zur Bearbeitung geben lassen und dann wird dieser bearbeitet.
Ich sage also z.B: "
DECLARE @Datensatz AS Integer
SELECT TOP 1 @Datensatz = Datensatz FROM Priodatensaetze WHERE InBearbeitung = 0 ORDER BY Prioritaet
UPDATE Priodatensaetze SET InBearbeitung = 1 WHERE Datensatz = @Datensatz
SELECT @Datensatz
" (nur Beispiel, das ganze ist dann noch mit ein paar Joins und mehr Spalten).
Ich muss aber nun irgendwie verhindern, dass wenn 2 oder 3 Mitarbeiter wirklcih mal zur ziemlich identischen Zeit auf den "Nächste offene Datensatz" klicken, dass 2 Mitarbeiter den gleichen Datensatz erhalten.
Klar, ich könnte jetzt in meinem .NET Projekt eine Art Warteschlangensystem aufbauen, was die Datensätze abruft und ausgibt. Diesen Weg wollte ich aber eigentlich vermeiden, da die Abfrage doch recht winzig gegen die Datenbank ist.
Gibt es irgendwie rein SQL mäßig die Möglichkeit, dass niemals 2 gleichzeitige Zugriffe den gleichen Datensatz erhalten, sondern einer nach dem anderen? Die Reihenfolge ist dabei vollkommen egal. Mit einer Art Lock oder sowas? Evtl. tritt der Fall produktiv ja auch niemals auf, da die gesamte Abfrage nur 0,5-1 Sekunden dauern wird. Aber ich habe Angst, dass es doch mal passiert, falls z.b. mal auf einer der Tabelle, die gejoint werden, z.b. Locks sind, auf die gewartet wird und dadurch die Abfrage doch ein paar Sekunden länger dauert.
Die gleichzeitige Bearbeitung des selben Datensatzes wäre fatal, da hier bei der Bearbeitung mehr passiert, als nur ein paar Daten zu überarbeiten.
Aktuell ist noch der SQL Server 2012 im Einsatz.
Comment