Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

References:

Overview

This user story is related to CPS-875 CM Handle State: Watchdog-process that syncs 'ADVISED' CM Handles wherein locking the database is an essential step of the process.

Recap of watchdog process:

  1. Wake up on a specified schedule
  2. Identify node with state ‘ADVISED’
  3. Lock database, update timestamp, unlock the database
  4. Model sync
  5. Update state of the node to ‘READY’

In step 3 of the process, it is necessary to lock the database in order to avoid multiple instances of NCMP updating the records.

It is identified that a ‘lock’ can also be implemented in the DB plugin, CPS, and the client (NCMP) or combination of these.

Locking method scenarios


ScenarioDescription
1Only 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
2anchor 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'

Issues and decisions


DescriptionIssuesNotesDecisions
1Scenario #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
    • 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
2To 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
  • No labels