27.7.2.1 JSON Duality Views—Concurrency

Concurrency is handled as follows:

1. The user reads data (using SELECT), storing it locally.

2. The user modifies the local copy of the data, leaving the generated etag value unchanged.

3. Execution of an UPDATE statement reconstructs the object (including metadata) using SELECT and persists any changes only if the reconstructed state (that is, the result of ETAG() on the reconstructed object) matches the state last read.

4. If the etag values do not match, MySQL raises an error, which applications can handle by re-reading the data and retrying the operation if desired.

See the descriptions of the individual tables for more information.

You should be aware that one INSERT, UPDATE, or DELETE statement on a duality view may lead to multiple insert, update, or delete operations on the view's base tables.

The etag value serves as a control value only, and is not replicated; it is generated at SELECT or UPDATE execution time.

BLOB types are stored as binary but represented in base64-encoded format when projected as SELECT output. This means that the etag value can be different when run with the same input as a BLOB, and as hand-crafted base64-formatted string.

A JSON document which is used as input for data modification operations is validated to make sure that its schema matches that of a JSON document generated by the JSON duality view.