2020-08-26 Meeting notes

Optimistic Record Locking

TC

Review issues (Tech Debt - DEBT-1, UXPROD-1752)  and discuss short term actions:

There was MODINVSTOR-516: Cannot safely update holdings and items concurrently for any given instanceClosedPreview which should be fixed by RMB-388: PostgresClient.getById with transaction, with "SELECT … FOR UPDATE"ClosedPreview

These issues will be resolved based on serializing activity as opposed to a fundamental design change to address optimistic locking.

Addressing optimistic locking is not likely to be addressed by a single/core team, but likely all backend teams would need to make modifications. In other words, a very big deal. Per UXPROD-1752:

• optimistic locking – each record state is marked with a "version number" (or a timestamp, hash, etc) which is returned to the client along with the record. The client includes the version number during the update and the server checks that the version hasn't changed before it writes the record back. If the record is dirty (version doesn't match) the update is aborted. In practice for a REST API (typical FOLIO uses case) this means using ETag with a combination of If-Match conditional request and 412 (precondition failed) and 409 (conflict) error codes.

Note that ETags (above) approach may not solve all use cases (batch, pub-sub oriented), etc.

Could "define the requirements"... and put the burden on modules/teams to come up with their own solution... but then we'd have the challenge/cost of potentially independent solutions and separate implementations.

ACTIONS:

1) Ask @Jakub Skoczen when UXPROD-1752 might fit on Core:Platform's roadmap

2) Define a recommended standard/approach (e.g. ETags)

3) Get confirmation of this issue's urgency

 Plan to review Tech Debt

@Mike Gorrell  

Discuss how we will go about reviewing Tech Debt 

3 steps:

1) Triage the list; what's active, what's the priority, etc. - ACTION - TC members to review list, update/close/etc. in prep for meeting September 9 where we will review entire list together

2) Assign appropriate items to TC members (based on priority, etc.)

3) Define the expectations of TC

Updates on open items

TC

UI Testing: @Zak_Burke

• Dilemma is that Big Test 2.0 is not ready and while it represents an opportunity we have needs right now.

• No matter what we are looking at making changes to existing tests in order to move to a new/updated framework

• Might be OK to have multiple frameworks

• Expect recommendation in the next 2 weeks

Defining Data Types (reference data): @Jakub Skoczen

• Initial meeting is set for tomorrow (8/29)

SAML/SSO issues: @Tod Olson

• Conversation starting

NEXT WEEK

Architectural Blueprint review