Verwalten von Concurrent Access

Question

Ich habe eine Anwendung, die eine Liste von Mitarbeitern verwaltet. Benutzer (Admins) in der Anwendung haben die Möglichkeit, diese Mitarbeiter zu erstellen und zu bearbeiten. Ich möchte den Bearbeitungszugriff eines Mitarbeiters sperren, während ein anderer Benutzer ihn bearbeitet.

Ich habe festgestellt, dass ich optimistischen Nebenläufigkeit verwenden kann, wenn der zweite Benutzer versucht, es zu bearbeiten, kann er nicht. Der Nachteil dieser Lösung ist, dass der Benutzer Zeit mit der Bearbeitung des Mitarbeiters verschwenden kann (besonders wenn viele Parameter bearbeitet werden müssen) und wenn er auf Bearbeiten klickt, wird er die neue Version vom Benutzer vor ihm bearbeiten lassen.

So suche ich einen Weg, um den gleichzeitigen Zugriff im Code und nicht in JPA zu verwalten.Wenn der Benutzer auf die Bearbeitungsseite des Mitarbeiters X zugreifen will, erhält er eine Nachricht, dass der Benutzer ADMIN2 diesen Mitarbeiter jetzt bearbeitet . Und er kann nicht auf den Mitarbeiter zugreifen, während ADMIN2 den Benutzer noch bearbeitet.

Gibt es Standards, die verwendet werden, um diese Art von gleichzeitigen Zugriff zu verwalten? Wenn nicht, wie denkst du, kann ich diesen gleichzeitigen Zugriff verwalten?

Answer 1

Wenn Sie wirklich implementieren möchten, was Sie beschreiben, würde ich eine editing Spalte in der entsprechenden Tabelle hinzufügen, wo Sie markieren, dass die Bearbeitung beginnt. Dann, bevor Sie mit der Bearbeitung beginnen, überprüfen Sie diesen Booleschen Wert und handeln mit Ihrer Nachricht. Mit anderen Worten: Eine solche Sperrung auf DB-Ebene ist bei mehreren Transaktionen kaum möglich und wäre eine Gefahr (ich nehme an, dass die Bearbeitung des Mitarbeiters ein langer Prozess ist, weit entfernt von der Transaktion) und Sie implementieren es am besten selbst (Vergessen Sie nicht, den Booleschen Wert editing nach dem Speichern oder nach dem Abbrechen zu entfernen).

Answer 2

Es gibt keine integrierte Möglichkeit, dies in JPA zu tun. JPA2 unterstützt pessimistic locking, aber dies ist ein Konzept, das mit Transaktionen verknüpft ist und daher nicht das ist, was Sie brauchen.

Auch Sie wollen eigentlich nicht, und wenn Sie vor 10+ Jahren waren, als (einige) Quellcodeverwaltungssysteme pessimistisches Locking ('gute alte Quelle sicher) verwendeten, werden Sie wissen, warum dies ein schlechter ist Idee im Vergleich zum heutigen Git.

Was Sie wirklich brauchen, ist eine Möglichkeit, die gleichzeitige Änderungen zusammenzufassen, genau wie bei einem Git-Merge-Konflikt. Anstatt die Änderungen des Benutzers wegzuwerfen (wenn das Einfügen der optimistischen Sperre fehlschlägt), senden Sie seine geänderte Version und die aktuelle Version von der Datenbank zurück an die Benutzeroberfläche und lassen den Benutzer die beiden Versionen zusammenführen und erneut speichern.

Sie können auch auf die Geschichte/Auditing gehen, EclipseLink und Hibernate hat eine Möglichkeit zum Speichern mehrerer Versionen der gleichen Entität (im Grunde wie Git tut), so dass Sie Änderungen verfolgen können. Ich kenne dich mit JPA aus, und mit einem guten UX-Designer ist es möglich, ein System zu bauen, das viel besser funktioniert als jedes pessimistische Locking - und selbst wenn du versuchst, pessimistisches Sperren mithilfe einer 'Editier'-Spalte zu erstellen Für den Fall, dass zwei Anwendungen verwendet werden, muss die optimistische Sperre verwendet werden. Klicken Sie gleichzeitig auf die Bearbeitungsschaltfläche für die gleiche Ressource. ;-)