Documentation

Implements the database access and marshalling of the object. while the database access must be strict, the marshaling must be lazy if, as is often the case, some parts of the object are not really accesed. If the object contains DBRefs, this avoids unnecesary cache lookups. This method is called within atomically blocks. Since STM transactions retry, readResourceByKey may be called twice in strange situations. So it must be idempotent, not only in the result but also in the effect in the database . However, because it is executed by safeIOToSTM it is guaranteed that the execution is not interrupted.

hopefully optimized read of many objects by key.

To write into persistent storage. It must be strict. Since STM transactions may retry, writeResource must be idempotent, not only in the result but also in the effect in the database. . However, because it is executed by safeIOToSTM it is guaranteed that the execution is not interrupted. All the new obbects are writeen to the database on synchromization, so writeResource must not autocommit. Commit code must be located in the postcondition. (see setConditions) Since there is no provision for rollback from failure in writing to persistent storage, writeResource must retry until success.

multiple write (hopefully) in a single request. That is up to you and your backend . Defined by default as 'mapM_ writeResource'

Delete the resource. It is called syncronously. So it must commit