Versions Compared

Old Version 3

changes.mady.by.user Darsi Rueda

Saved on

compared with

New Version 4

changes.mady.by.user Darsi Rueda

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Time

Item

Who

Notes


Optimisitic locking workarounds


Stanford tested two scenarios using the same Okapi endpoint that we use in our DAG (/instance-storage/batc/synchronous?upsert=true). In both tests, I added a new _version property with a value of 1.

For the first test, all the records existed in FOLIO and the upsert POST succeed with each record's _version property incremented to 2.

For the second test, the records did not exist in FOLIO and the upsert POST succeed and each record's _version property stayed as 1.

--

Could disable all through testing phase, and always set _version = 1.  Or at least could test this.


“Upsert works” Jira

MODINVSTOR-924  - new Jira asking for a new api that disables optimistic locking while api runs
Lots of comments on this Jira both for and against. Some folks worried about bulk updates happening during work day and having conflicts.  Others supporting need for multiple loads during migration process, and for batch instance updates.

Julian includes workarounds, including disabling optimistic locking:
ALTER TABLE instance DISABLE TRIGGER set_instance_ol_version_trigger;
ALTER TABLE instance ENABLE TRIGGER set_instance_ol_version_trigger;

set_instance_ol_version_trigger could disable optimistic locking at the database level, for instances, holdings, items.  Postgres commands.

Decided we will do some experimenting with disabling optimistic locking and load some records.  Then enable and load some more with version number, what problems will we run into?

We also should continue to fill out our document with the impact of this problem, AND comment on the Jira ticket so the develops see our comments immediately.  So we’ll advocate for ourselves on two fronts.









...