It needs to be clear to users the level of atomic operations supported by the CPS
Decision
The CPS will not use an external transaction manager. Where the underlying DBMS provides transactions, these will be exposed by the SPI and used by the CPS core library.
The CPS core library will expose a simple session concept to co-deployed modules. This will enable fine grained control of the order of changes. This will help ensure that complex validation (e.g. WHEN clause) succeeds.
For REST users, the session concept will not be exposed. Where documents representing several operations are input, the CPS will follow the order of the input document, and fail fast. Any failures will be abandoned (if the underlying DBMS supports transactions) and a failure response will be returned to the REST user.
Details (REST interfaces)
There will be no explicit control of transactions using the REST interface.
The REST interface will provide a best effort approach to persisting validated data.
Internally the CPS will use transactions if they are supported by the underlying DBMS.
For requests that include multiple discreet operations (described by an input document), the CPS will execute the discreet operation in the order defined in the input. In the event of failure:
- fail fast
- return an error response (indicating where in the document the failure occurred)
- changes to the underlying DBMS will not be written, where the DBMS supports transactions
Details (Java interfaces, co-deployed)
The co-deployed application will have explicit control of the transaction
- Many applications need to be aware of the capabilities of both the managed network and the persistence to apply changes efficiently – Given the application already must assume this responsibility, it makes little sense to split the responsibility
- The ordering of multiple inter-related objects in a single structure is very difficult to specify in a model driven way – It is not reasonable for CPS to assume this responsibility
- The application is anyway aware of complex operations between participants;
Operations (API calls) will work on single objects (not structures including multiple objects and references)
- Clearly delineates the CPS/Application responsibility split
- Avoids complexity in the CPS implementation
- Application implementation is already aware of inter-object relationships
The application may make multiple calls to the CPS API within a single transaction
- The application controls the scope of the transaction
- Updates to multiple objects are often required to be seen as atomic
- The CPS will not sequence updates to multiple objects in a single operation (API call)
- The application is aware of the capabilities of network and persistence
YANG model constraints will be enforced (approach, check what can be checked, when it can reasonably be checked):
@commit for complex constraints e.g. referential integrity, MUST,…;
@operation (API call) for simple constraints e.g. ranges
- Complex inter-related objects may have constraints that span objects
- It is possible that several objects need to be updated ‘simultaneously’
- The CPS will operate on one object at a time
- There is a possibility that some inter-object constraint checks would fail
- "When Clause" is a triggered clause that is checked when a particular condition occurs. For example, when a particular leaf has a value another entry might be checked.
PoC will start with simple session management, including only the underlying persistence technology
CPS will never initiate a transaction. CPS will not operate without a transaction
Write-then-read consistency is a property of the underlying DMBS – this is deployment specific
Discussion
Issue was discussed in the weekly meeting