benutzerverwaltung absichern

[gast123]

Hallo,

ich schreibe zur zeit an einer kleinen bentuzerverwaltung, eine webbanwendung. jetzt frage ich mich wie man am besten sicherstellen kann das ein datensatz vor simultaner bearbeitung geschützt ist. also nicht das der kunde sein passwort ändert und meinetwegen ein admin zurselben zeit das selbe bei diesem kunden machen will. ich habe in dieser richtung leider noch keine erfahrung und wäre dankbar wenn ich da ein paar denkanstöße bekäme.

ich habe eine kundenklasse als bean, sprich aktueller kundensatz wird aus der db geladen und dargestellt und umgekehrt änderungen am kunden von der weboberfläche in die db geschrieben.

danke,
gast123

 

[DP]

stichwort "lock table"

 

[gest123]

hallo,

danke erstmal. ich hab mir das mal ein wenig angesehen...also dieses lock table ist ja ein scheinbar db-statement. ich benutze eine oracle db. meine änderungen an den kundendatensätzen betreffen meist 2-3 tabellen die zusammenhängen. daher habe ich ich diese 2-3 updates javaseitig in transaktionen gesetzt:

connection.setAutoCommit(false);
UPDATES DER BETREFFENDEN TABELLEN
connection.commit();
connection.setAutoCommit(true);
(oder rollback wenn was schiefgelaufen ist)

nun habe ich bei einigen lock tables beschreibungen für oracle gelesen, das oracle das bei transaktionen wohl selber macht...stimmt das? bzw. wird bei connection.setAutoCommit(false) ein db-spezifisches lock angefordert?

wenn nicht, wie mache ich das am besten? setzt man diese lock tables-befehle wie ein statement.execute ab? und wegen dem mode bin ich mir auch unsicher...ich möchte ja nur das in der kundentablle der spezielle kundendatensatz gesperrt ist, alles andere kann bearbeitet werden.

weiter noch: am liebsten wäre mir das wenn jemand zweites auf den selben kundendatensatz zugreift und sieht das da schon ein lock drüber ist, eine fehlermeldung/fehlercode kommt, denn ich dann mit einer meldung ala "der betreffende kunde wird gerade bearbetitet, versuchen sie es später nochmal" an den benutzer zurückgeben könnte...

danke,
gast123

 

[DP]

dann machste ein neues feld in der tabelle und setzt einen flag wenn jemand am bearbeiten ist.

beim lesen fragst du das flag immer ab und kannst entsprechende meldungen ausgeben.

so ist das einfacher als mit dem lock tables.

 

[gast123]

Hallo DP,

danke nochmal für die Anmerkungen, aber diese Option habe ich leider nicht. Die Tabellen dürfen nicht geändert werden.

danke,

gast123

 

[DP]

dann ein singleton dem gesagt wird welche kunden in bearbeitung sind.

 

[KSG9|sebastian]

Ind bei nem Clusterbetrieb hast du dann ein nettes Problem mit mehreren VM's

 

[DP]

noch ne lösung: vor dem bearbeiten des kunden ne rundmail an alle mitarbeiter dass der kunde gerade bearbeitet wird :lol:

 

[gast123]

Hallo nochmal,

sehr witzig. ihr seit heut alle gut drauf was? ändert nichts an der tatsache das es für mich ein echtes problem ist.
worauf bezieht sich das clusterproblem? auf den singleton vorschlag? ich hab ja kein problem mit lock tables zu arbeiten, nur ist mir etwas unklar welcher modus da für mich der angebrachteste wäre und die frage was db-seitig passiert wenn ich ein connection.setautocommit(false) setzte steht auch noch...

wie löst man denn sowas sonst? ich mein selbst wenn der zweite bearbeiter wartet bis das lock freigegeben wird und dann seine änderungen einträgt, so besteht doch immer noch das problem das die vom ersten bearbeiter gemachten änderungen von alten daten überschrieben wird (beim zweiten ändern). und irgendwie kann ich mir schwer vorstellen dass ich der erste mensch bin der vor diesem problem steht...???:L

gast123

 

[DP]

wir sind immer gut drauf

autocommit(false) bewirkt, dass dml-statements erst duch ein explizites commit in die db geschrieben werden.

aber das mit dem lock table kannste imho für dein problem knicken.

das clusterproblem bezieht sich auf den singleton.

kannst/darfst du denn neue tabellen anlegen?!

 

[gast123]

Hallo,

nein an der datenbank kann ich nichts ändern.
was das singleton angeht...ich müßte da ja ne liste mit alle z.zt. bearbeiteten kunden halten...hmm...
und wieso denkst du das mit lock tabels nicht hilft? ist doch im prinzip das was ich suche...

gast123

 

[DP]

ne, brauchst keine liste machen. machste ne methode lockKunde und unlockKunde... die kundennummern werden dann in einem array oder einer collection gesammelt.

beim bearbeiten prüfst du ob die kundennr. dort gesetzt wurde.

das mit den locktables hilft schon. musste nur abfangen wenn einer in der bearbeitung seinen browser etc. schliesst. nicht dass der satz dann für alle ewigkeiten gesperrt ist.

 

[gast123]

wie fängt man denn bitte ab, ob der benutzer seinen browser schließt? soviel ich weiß geht das doch gar nicht, der server bekommt das doch gar nicht mit...
selbst wenn...ist es nicht egal ob der user seinen browser schließt oder nicht? der request ist abgeschickt und das update wird durchgeführt und das lock beendet, egal ob der user nach dem absenden den browser schließt oder nicht. oder mach mir mal ein konkretes beispiel dafür...wenn ich mich irren sollte.

naja ob nun liste oder collection...ich muß immer beim singleton halt immer durch die latte bearbeiteter kunden, aber prinzipiell nicht schlecht...

danke,
gast123

 

[DP]

ich weiss ja nicht wie du das handhabst.

bei mir ist das so wenn einer nen auftrag öffnet, wird dieser enstprechend markeirt bis der auftrag gespeichert oder sonstig verlassen wird.

wenn du dein lock table nur beim speichern setzt hilft dir das nichts wenn mehrere benutzer sich den kunden auf den schirm holen und bearbeiten können.

speichern die dann zu unterschiedlichen zeiten ab, hilft dein lock table herzlich wenig

 

[KSG9|sebastian]

eben:
Normaler Ablauf:

1. User lässt sich eine Übersicht anzeigen
2. User klickt auf "Bearbeiten"
3. Wenn Auftrag gelockt: nichts machen
4. Sonst Auftrag sperren
5. User klickt speichern oder abbrechen
6. Evtl. update ausführen, Auftrag entsperren

Wenn das ganze nur Admins benutzen dann kannst du den Auftrag nach 30min automatisch entsperren. Aber das ist halt immer so ne Sache...

 

[Tobias]

Optimistisches Locken: Jeder Datensatz erhält ein Feld, in das die aktuelle Versionsnummer des Datensatzes geschrieben wird. Bei einem Update wird verglichen, ob das Versionsfeld immer noch den selben Wert hat wie zum Zeitpunkt des Lesens. Wenn nicht, wird eine entsprechende Warnung ausgegeben, ansonsten wird der Datensatz gespeichert.

mpG
Tobias

 

[Yzebär]

Du kannst deinen Datensätzen eine zusätzliche Spalte "VersionId" spendieren. Diese wird immer geändert, wenn der Datensatz geändert wurde (im einfachsten Fall ein int-Zähler). Wenn ein User einen Datensatz lädt, lädt er automatisch die aktuelle VersionId. Hat er die Daten bearbeitet und will Speichern, wird die ursprüngliche geladene mit der aktuell in der DB vorhandenen VersionId abgeglichen. Wenn diese nicht mehr übereinstimmt, hat jemand von anderer Stelle die Daten bereits geändert. So kann man zumindest feststellen, ob Daten während der Bearbeitung von anderer Stelle verändert wurden.

 

[DP]

Optimistisches Locken: Jeder Datensatz erhält ein Feld, in das die aktuelle Versionsnummer des Datensatzes geschrieben wird. Bei einem Update wird verglichen, ob das Versionsfeld immer noch den selben Wert hat wie zum Zeitpunkt des Lesens. Wenn nicht, wird eine entsprechende Warnung ausgegeben, ansonsten wird der Datensatz gespeichert.

mpG
Tobias

Du kannst deinen Datensätzen eine zusätzliche Spalte "VersionId" spendieren. Diese wird immer geändert, wenn der Datensatz geändert wurde (im einfachsten Fall ein int-Zähler). Wenn ein User einen Datensatz lädt, lädt er automatisch die aktuelle VersionId. Hat er die Daten bearbeitet und will Speichern, wird die ursprüngliche geladene mit der aktuell in der DB vorhandenen VersionId abgeglichen. Wenn diese nicht mehr übereinstimmt, hat jemand von anderer Stelle die Daten bereits geändert. So kann man zumindest feststellen, ob Daten während der Bearbeitung von anderer Stelle verändert wurden.

er kann an den tabellen nichts ändern