It needs to be clear to users the level of atomic operations supported by the CPS
Decision
T.B.D.
Details (Java internal interfaces)
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
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