Mutex und WebServices

[Timbo Jones]

Hallo

ich habe mir einen WebService geschrieben der Räume mit Veranstaltungen belegt.
Die folgenden Funktionen sind implementiert:
roomSearch(..)
roomAdd(..)
roomDelete(..)
roomBooking(..)
roomRelease(...)

Nun muss ich verhindern das z.B. ein gleichzeitiger Zugriff auf das Buchen eine Raumes stattfindet.
Das deklarieren einer Funktion mit "sychronized" in Java bringt ja an dieser Stelle nicht weiter. Der Mutex müsste ja auf dem Server laufen. Gibt es dafür für eine Apache Tomcat eine Lösung. Oder wie wird das Problem sonst gelöst.
Ein Link mit einem Bsp oder einer Beschreibung wäre super

Danke Euch im Voraus

Gruß

timbo

 

[Thomas Darimont]

Hallo,

soll das nur ein Beispiel sein ohne Datenbank? Mit Datenbank macht man das mit Transaktionen und pessimistischem / optimistischem Locking.

Ansonsten kannst du (wenns nur ein Beispiel sein soll) auch die java.util.concurrent Locks verwenden.

Gruß Tom

 

[Timbo Jones]

Ansonsten kannst du (wenns nur ein Beispiel sein soll) auch die java.util.concurrent Locks verwenden.

Ich weiss zwar nicht genau was du damit meinst "wenns nur ein Beispiel sein soll" aber als Ergänzung:
Meine Daten stehen in einer mySQL Datenbank die ich auslese.

Gruß

 

[Thomas Darimont]

Hallo,

Ich weiss zwar nicht genau was du damit meinst "wenns nur ein Beispiel sein soll" aber als Ergänzung:
Meine Daten stehen in einer mySQL Datenbank die ich auslese.

Hätte ja sein können, dass du das als einfaches Beispiel ohne Datenbank machst bzw. der Einfachheit halber eine Datenbank vorgegaukelt hättest aber egal...

Das kannst du über mehrere Arten lösen.
Beispiel:

Tabellen:

Resources
id, description, ...., available

Bookings
id, resourceId, startDate,endDate,requester,timestamp

Bei der Buchung einer Resource wird zu begin geprüft, ob die entsprechende Resource vorhanden ist
(Resource in Resources-Tabelle?). Anschließend wird geschaut, ob in Bookings ein Eintrag mit der entsprechenden
Resourceid existiert.
Nun starten wir eine neue Datenbanktransaktion{
Ist das nicht der Fall wird ein entsprechender Bookingeintrag in Bookings hinzugefügt.
Anschließend wird auf die Resources Tabelle der entsprechende Resource-Satz geupdated:
int updateCount = update resources (available) values (1) where id = theResourceId and available = 0;

Nach diesem Statement analysiert man den updateCount und schaut nach, ob tatsächlich 1 Datensatz geupdated wurde.
Ist der Updatecount = 1 lief alles wie gewünscht -> Datenbank transaktion kann committed werden.

Ist der Updatecount = 0, dann wurde die Resource parallel von einem anderen Buchungsprozess zuvor belegt
-> dies wird durch das bedingte updatestatement in der where klausel via: ... and available = 0 sichergestellt.
-> In diesem Fall rollen wir die Transaktion zurück.
Dadurch wird auch automatisch der zuvor in der Bookings Tabelle angelegte Satz wieder gelöscht
(bzw. gar nicht erst "wirklich" in die Tabelle geschrieben).
}

Das ganze nennt man dan optimistisches Locking auf Datenbankebene.

Gruß Tom