Page Comparison

It needs to be clear to users the level of atomic operations supported by the CPS

Decision

T.B.D.

...

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

Drawio
border true diagramName REST_Atomic_behaviour simpleViewer false width links auto tbstyle top lbox true diagramWidth 671 revision 1

Details (Java interfaces, co-deployed)

The co-deployed application will have explicit control of the transaction

...

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 04 Sep 2020