Du musst genauer beschreiben was Du mit den Locks in Oracle machst und wie Du sie verwendest.
Ich kenne z.B. den Unterschied zwischen den beiden Oracle Funktionen nicht.
Das Äquivalent zu einem “exlusive” Lock ist vermutlich pg_advisory_lock(). Das “release on commit = false” klingt so (reine Spekulation!) als wäre das, das gleiche Verhalten wie ein session level advisory lock (man muss also den Lock manuell freigeben, es passiert nicht automatisch beim commit).
Mmh, ich kenne das von Oracle auch nicht.
Das Problem ist wahrscheinlich nicht, einen manuellen Lock hinzubekommen. Das macht man ja oft schon unfreiwillig mit den Standardwerkzeugen.
Bei der Migration sollte man
a) aufpassen, dass man nicht Dinge migriert, die man auch netter lösen kann.
b) wenn a) nicht geht, das Locking Konzept der Altanwendung verstehen und schauen, wie es in die migrierte Anwendung bzw. aktuelle Anwendungsfälle passt.
In meiner alten Firma, war ein erheblicher Teil der Logik in Oracle-Packages abgelegt. Wir haben diese Technik verwendet, für Proceduren/Codestellen die nicht gleichzeitig mehrmals ausgeführt werden dürfen. Das waren Verarbeitung per PL/SQL.
Ob es vergleichbares in PG gibt, weiß ich nicht.
Das würde man über einen advisory lock am Anfang der Prozedur/Funktion machen, z.B. mit pg_try_advisory_lock (42) und wenn das nicht erfolgreich ist, dann wird die Prozedur wieder verlassen (oder Du verwendest pg_advisory_lock (42) und das wartet dann bis der Lock zugeteilt wurde.
Für jede Prozedur musst Du einen andere Wert verwenden.
Am Ende der Prozedur gibst Du den Lock mit pg_advisory_unlock(42) oder pg_advisory_unlock_all() wieder frei.
In one procedure below is the portion of code using.I’ve to migrate that in Postgresql.I’ve found
pg_advisory_lock but am not sure how to implement that.
No, pg_try_advisory_lock(42) does not return a handle but true or false on success. What oracle code names LOCK_STATUS perhaps, while I don’t know why it’s build on unlock.
I think 42 can be seen as (a user predefined) LOCK_HANDLE here, since postgres advisory lock implementation doesn’t offer names for locking, just plain numbers (big int);
So a migration would omit lock_handle request and use a self chosen handle of Your flavour.
So You are on your own, defining number (lock_handle) for specific purposes and have to follow strictly your number model of specific locks / (topics).
Maybe it’s a good idea to mimic oracle’s way of naming these handles. Create a table with topics and handles, where the developer (you) is forced to pull numbers from by topic. (and of course release when done or on error)
The parameter to pg_try_advisory_lock() is just a unique number to identify a unique “lock resource”. That’s probably the equivalent to the ‘GETUNQCUSTNUM’ parameter in Oracle. You can not use descriptive “names”, you need to use a unique number for each “lock resource” you want to synchronize one.
And can be please switch back to German? This is a German forum.