Versions Compared

Old Version 2

changes.mady.by.user Lee Anjella Macabuhay

Saved on

compared with

New Version 3

changes.mady.by.user Lee Anjella Macabuhay

Saved on

Key

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

...


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