Kein richtiges optimistic locking mit oracle möglich?

[ARadauer]

Hi ich hab eine generelle Frage zu Hibernate in Verbindung mit einer Oracle Datenbank..
Angenommen ich habe FlushMode.Auto und ich möchte im Grunde nur optimistic locking. Ich will kein pessimistic locking haben.
Das schaffe ich nicht 100%ig oder, da mir bei einem möglichen update durch ein flush die oracle datenbank automatisch die Zeile sperrt... oder?

 

[stg]

Wenn du Hibernate / JPA benutzt, dann nutzt du doch vermutlich auch das HighLevel-Locking von JPA, oder nicht? Wieso sollte die Datenbank da irgendwas sperren?
Oder willst du das Locking LowLevel direkt auf der Datenbank realisieren?

 

[Dompteur]

Wieso sollte die Datenbank da irgendwas sperren?

Sobald durch ein Flush Daten aus Java in der Datenbank persistiert werden, lockt Oracle diesen Satz. Bis zum Ende der entsprechenden Transaktion kann dieser Satz dann von anderen Transaktionen nicht mehr verändert werden.

Man kann das natürlich als Bruch des 100% Optimistic-Lockings sehen.

In der Praxis hat das aber Vorteile:

Optimistic Locking geht ja davon aus, dass es nur äußerst selten zu Kollisionen kommt. Wenn dann eine Kollision passiert, dann werden die Veränderungen des "Verlierers" zurückgenommen.
Sobald nun aber ein Satz verändert wird und ein zweiter Mitspieler diesen Satz ebenfalls ändern möchte, haben wir eine deutlich höhere Wahrscheinlichkeit, dass es zu einer Kollision kommt. Sie ist zwar nicht 100% - der erste Mitspieler könnte ja ein Rollback machen - aber in der Praxis behandelt man das so als wäre es bereits eine Kollision.

 

[stg]

Was Optimistic Locking ist, ist mir schon klar. Ich sehe nur nicht, was das hier mit der Wahl der Datenbank zu tun haben soll. Oracle sollte hier gar nichts sperren, wenn mit JPA gearbeitet wird. Das übernimmt doch alles der EntityManager, oder nicht? Außerdem schreibt ein Flush auch nicht auf die Datenbank, ein Flush ist kein Commit. Geschrieben wird erst zum Ende der Transaction in der Anwendung. Zu diesem Zeitpunkt wird dann auch vom EM ggfls ein Version-Field o.Ä, gecheckt ...

 

[Dompteur]

Natürlich schreibt ein Flush auf die Datenbank. Mit einem Flush werden alle Änderungen, die Hibernate im Speicher hält auf die Datenbank durchgeschrieben.
Siehe dazu : Chapter 10. Working with objects

Später werden diese Änderungen dann mit commit abgeschlossen oder mit rollback zurückgenommen.

Da also Daten auf die Datenbank geschrieben werden, hängt das (Locking-) Verhalten auch von der verwendeten Datenbank ab.

 

[stg]

Danke fürs Richtigstellen. Ich muss wohl noch einmal genauer nachlesen was wann exakt passiert und klinke mich hier dann mal wieder aus

 

[ARadauer]

Oracle sollte hier gar nichts sperren, wenn mit JPA gearbeitet wird.

Ich sehe das ähnlich.. oracle tut es aber...
Mir war es auch nicht 100%ig bewusst..

 

[KSG9|sebastian]

Warum FlushMode=Auto? Auch EntityManager#flush() sehe ich häufig - ist aber imho unschön. Transaktion auf, do stuff, flush/commit. Ein zwischenzeitliches flush() bringt u.U. einige Probleme mit.