Overview (Resoa BTREE Grid Persistence Service)

Other Packages
Package	Description
org.resoa.persistence	This is the main package you need for working with Resoa persistence.
org.resoa.persistence.autokey
org.resoa.persistence.btree	This package provides the BTREE implementation of Resoa persistence.
org.resoa.persistence.core
org.resoa.persistence.exception	This package provides the Resoa persistence specific exceptions.
org.resoa.persistence.journal
org.resoa.persistence.journal.service	This package contains the Resoa Service implementations of Persistence ExecLogService is used for storage synchronization during node startup.
org.resoa.persistence.model
org.resoa.persistence.rdbms

Resoa Persistence - BTREE search, JSON Object serialization with reference resolution

Resoa persistence is a generic, JSON based persistence solution, especially designed for Resoa services.
The storage itself is a BTree key/value system. By default we use Oracle Berekely DB Java Edition.
Resoa persistence provides:

Domain based persistence model, linked to XSD defined business objects (check the Resoa service implementation guide)
MASTER / SLAVE based transaction processing with ACID support.
Automatic Class<?> and List<?> reference resolution support.
Policy based transaction processing. Check the Javadoc of LogfilePersistPolicy and MasterCommitPolicy for more information about.
Hot backup services and startup node synchronization, so new persistence nodes can join during runtime.
Interface for a BTree based persistence storage backend, an implementation for the Oracle Berkeley DB is included.
Compression and encryption support on entity level.

Resoa persistence does not require its own data model but directly plug’s into Resoa’s Business Service architecture. Resoa Nodes will automatically create and maintain your BTREE files during startup

Every Resoa node has its local storage file, so read requests can be answered always by a local BTREE search, which is very fast. Moreover, Resoa Persistence additional provides a JCS based caching, so object retrieval not necessarily needs a hard disk access.

Store and Delete transactions are managed by the internal Grid communication by MASTER and SLAVE principle. SLAVES forward Store and Delete requests always to the Service Domain MASTER node, here it is processed into physical storage first. After success, the transaction result is broadcasted to all SLAVE nodes of the domain, they will now process the request sequentially into their local storage too. The LockManager instances on each node will guarantee transaction safety during the grid transaction processing between MASTER and SLAVES.

The Resoa Controllers monitor the grid and ensure, that a MASTER is assigned for every deployed domain in any time. If all nodes for a domain have crashed, you can use the the Controller's logging utilities to indicate this FATAL error.

Resoa Persistence does a logging of every task execution, this way a hot back creation and re-synchronization of new joining Resoa nodes during runtime is possible.