Only anchor table row is locked

• can be implemented through PostgreSQL

• Client options

  1. query for 'LOCKED' anchor every mutation

  2. handle failure for 'LOCKED' anchor

anchor and every fragment associated with the anchor is locked

• locks every relevant fragment row in the fragment table associated with the anchor

• adds new exception to identify that fragment is 'LOCKED'

Scenario #2 is chosen as the method for locking anchor

• locks all fragment when we lock metadata anchor i.e. metadata of all cm handle will be locked

  • metadata of every cm handle is frozen until the first lock is released

• we don't need to lock the anchor but lock just the fragment

  • locks only the relevant row 

  • this way client can lock another fragment in parallel

  • client (NCMP) can pass the XPath to specify the fragment they want to lock

• Options for scenario 2

  1. extend lock capability to the fragment

  2. change the model for storing metadata

• the team decided to go for option #1 for scenario 2 

  • don't need to specify anchor as it is given by FK

  • you need the path for the fragment

To implement a lock we must do it inside a transaction

• Session must be introduced in JAVA API (CPS CORE)

• query and 'LOCK FOR UPDATE' relevant rows in fragment table inside a transaction

• no persistency

• this will be a local transaction between the CPS instance and the database

• see CPS-899 Start and stop sessions on Java API

Locking of anchor on multiple namespaces