In https://jira.onap.org/browse/CPS-875 ,wherein the database needs to be locked in order to 'prevent multiple instances attempting to sync the same CM Handle' ,this user story is to determine the method to lock and unlock an anchor as part of that process.

Scenario #1: Only the row in the anchor table is locked.

• This can be implemented fairly easily in PostgreSQL with simple exposure by the plugin and CPS
• The client must either (a) check if the anchor is locked every time it mutates or (b) block as it tries to get a lock itself or (c) handle a failure because the anchor is locked.

Scenario #2: Every fragment referring to the anchor (FK) is also locked

• This one make more sense, but needs to be delegated to the plugin which will need to query and LOCK FOR UPDATE relevant rows in the fragment table.
• It adds a new exception (the check for lock no longer makes sense) fragment (YANG node) is locked – read operations will not suffer.
• 2 options
  1. Scenario #2, and extend to also allow for locking of YANG nodes (fragments)
  2. Change the meta-data anchor to a dataspace, and have an anchor for the meta-data of each cmHandle
     -
      
• Which methods should be overloaded with SessionID?
  • for anchor locking purpose
    • cps-ri
      • queryDataNodes?
      • getFragmentByXpath?
• exceptions?
• Transactions are usually ended by 'commit()' so all queries will be added when this is called 
  • rollback on a previous uncommitted query?

Solution

• Java API impl only
• Consider using Hibernate to lock 'entity'
  • see https://www.baeldung.com/jpa-pessimistic-locking
  • also consider https://www.baeldung.com/jpa-optimistic-locking (might depend on schema update to include 'version or timestamp' field )
• Decide on what is best for out our case optimistic/pessimistic locking
  • assume anchor-lock is relative rare use-case
  • assume time of lock will be kept very short by client
  • there will be always some contention
• Anchor entity gets locked, any associated dat (fragments etc are not beging locked, this could be future option) It is up to the client (in our case NCMp) to use this correctly where needed. 

• • Ensure JavaDoc explains this well

A/C

1. Document Pros and Cons
   1. Agreed type of lock to be used with CPS-Team  (pessimistic is proposed for now)
2. Demo anchor lock using real DB and Java API and SQL Client query or (test-container) unit test-code PESSIMISTIC
   1. when locked other client/thread lock should fail
   2. when locked, owner of lock can write  to anchor 
   3. when locked update to anchor by other client/thread should fail
   4. when locked other client can read
   5. when locked other client/thread cannot write
   6. when unlocked other client/thread can lock
   7. when unlocked other client/thread can write
3. Implement remaining code comments on Session implementation
   1. ConncurentHashMap see https://gerrit.onap.org/r/c/cps/+/128013/3/cps-ri/src/main/java/org/onap/cps/spi/impl/CpsDataPersistenceServiceImpl.java#89
4. Graceful shutdown (separate sub task). Open lock/session are closed on shutdown

Out-of-Scope

• Robustness
  • Investigation into default behavior of Postgress when sessions(transactions) are never closed (client crashes)
  • What are the client responsibilities