The MicroKernel
Design Goals and Principles:
- manage huge trees of nodes and properties efficiently
- MVCC-based concurrency control (writers don't interfere with readers, snapshot isolation)
- GIT/SVN-inspired DAG-based versioning model
- highly scalable concurrent read & write operations
- session-less API (there's no concept of sessions; an implementation doesn't need to track/manage session state)
- easily portable to C
- easy to remote
- efficient support for large number of child nodes
- integrated API for efficiently storing/retrieving large binaries
- human-readable data serialization (JSON)
The MicroKernel Data Model:
- simple JSON-inspired data model: just nodes and properties
- a node consists of an unordered set of name -> item mappings. each property and child node is uniquely named and a single name can only refer to a property or a child node, not both at the same time.
- properties are represented as name/value pairs
- supported property types: string, number, boolean, array
- a property value is stored and used as an opaque, unparsed character sequence
The Retention Policy for Revisions:
TODO specify retention policy for old revisions, i.e. minimal guaranteed retention period (OAK-114)
The Retention Policy for Binaries:
The MicroKernel implementation is free to remove binaries if both of the following conditions are met:
- If the binary is not references as a property value of the format ":blobId:<blobId>" where <blobId> is the id returned by {@link #write(InputStream in)}. This includes simple property values such as {"bin": ":blobId:1234"} as well as array property values such as {"array": [":blobId:1234", ":blobId:5678"]}.
- If the binary was stored before the last retained revision (this is to keep temporary binaries, and binaries that are not yet referenced).