#48 IMM: Support for transactionally safe reads

[Anders Bjornerstedt]

Migrated from:
http://devel.opensaf.org/ticket/3111

The Ccb concept as defined by the IMM SAF standard does not
include any support for safe reads. That is, object reads that
are protected and part of a ccb/transaction.

The closest thing it has to safe reads is the admin-owner concept.
By setting admin-owner for not just the objects to be changed,
but also for objects included in the read-set of the ccb, the risk
is reduced but not eliminated for the CCB being committed with an
inconsistent read-set. The reason the risk is not eliminated is
that concurrent CCBs are allowed under the same admin-owner.
Another reason is that it is all too easy for applications
to perform non-repeatable-reads using accessor-get or iterations,
without remembering to set admin-owner over the read objects.
I suspect that this is the rule rather than the exception.

The 'read-set' for a ccb/transaction is the set of objects that
the ccb/transaction needs to read (and have unchanged or only
changed by the same ccb/transaction) untill the ccb/transaction
terminates. The cardinal example would be an OI doing validation
in hte completed callback. In general the OI needs to validate the
changes not only within the limited context of the changed objects,
but also relative to other objects that may not be changed by that
specific transction. Currently all OIs would need to maintain inernal
copies of all config data that they manage to acheive that. With
safe-read this is no longer necessary. Some interrelated datamodels
may also be managed by several OIs. The safe-read mechanism
uses shaed locking allowing several OIs to safe-read access the same
objects from different CCBs.

This enhancement proposes to add an additional ccb related
function for reading an object and associating that read with
what is (or is equivalent to) a shared readlock.

The OpenSAF IMM implementation already implements exclusive
write locks for create/delete/modify operations in a ccb.
Thus a Ccb that succeeds in invoking such a mutating operation
will reserve exclusive write access to that object until the Ccb
is terminated by commit or abort. The exclusivity is only in
relation to other CCB operations (including safe reads).
The accessor and iteration APIs still allow other processes to
perform non repeatable reads, i.e. non transactional reads, i.e.
unsafe reads, concurrently with an open CCB that is mutating such
objects. Such unsafe reads are allowed without considering changes
pending in on going CCBs or what admin-owner is set for the object.

The new API that is proposed looks like this:

saImmOmCcbObjectRead(SaImmCcbHandleT ccbHandle,

    SaConstStringT objectName,
    const SaImmAttrNameT *attributeNames,
    SaImmAttrValuesT_2 ***attributes);

It has a signature very similar to saImmOmAccessorGet_2,
with the difference only in taking a ccbHandle instead of an accessorHandle.
The semantics of the API is identical to accessorGet with the exceptions that
any returned config attributes are from the latest version of the object that is
locked by this ccb.

This operation will succeed unless the object is write locked by another Ccb.
It will succeed if the object is not locked by other Ccbs or if it is only read-locked
(shared) by other Ccbs. Another Ccb trying to write lock this object when this
ccb has a shared read-lock will fail and have to wait at least until
after this ccb is terminated. Another Ccb trying to read lock this object when this
ccb has a shared read-lock will succeed and obtain a read-lock

A safe read on an object that is already write locked by the same Ccb for create or
modify will succeed, but not change the lock-type and will provide the current latest
version of the object in the context of the CCB. A safe read on an object that is already
write locked by the same Ccb for delete will fail with ERR_NOT_EXIST.

Thus any modifications done to the object by this ccb but not yet committed, will be
reflected in the result returned by the safe read call.

All of the above should be recognized as pretty much standard
transactional behavior for the OM API. What then about implementers
and the OI API? After all, one typically important type of
participant in a Ccb are the OIs performing validation of the CCb.
Validation should normally include reading both data modified by
the Ccb and reading data not modified by the ccb, but that still
needs to be part of the read-set for the transaction, to commit
without, violating integrity constraints.

The proposal is for the OI to obtain a ccb-handle using the
existing saImmOiAugmentCcbInitialize API. Then to use the above
suggested saImmOmCcbObjectRead API for such reads. Note that
the augmented ccb concept as introduced in A.2.11 only allowed
ccb-augmentation in the create/delete or modify callbacks, but
not in the completed callbacks. This would still be the case
for modifying ccb augmentations. However, reading ccb
augmentations will be allowed also in the completed callback.

The reason that it is possible to allow safe reads in the completed
callback is that such reads do not modify the base of the validation.

One more important thing to note here is that with the new proposed
safe read API, the OI only needs to record the DN and possibly
operation type for each create/delete/modify. It kan skip recording
the attribute values and instead read the objects using safe
read in a ccb-augmentation in the completed callback.

It still needs to record the DNs for the objects because this
enhancement does not propose any form of ccb related iterator

An important question is whether admin-owner has to be set for the
objects being safe-read. The answer is NO. Setting admin-owner is of
course allowed for objects only to be safe read. But it is readundant and
should be avoided since it will interfere with the concept of shared read
access.

[Anders Bjornerstedt]

The decision on the admin-owner issue is that the admin-owner need not
be set for the object being safe read and if it is set it need not match
the admin-owner of the ccb invoking the safe-read on it.

[Zoran Milinkovic]

https://sourceforge.net/p/opensaf/mailman/message/34960625/

[Zoran Milinkovic]

default(5.0):

changeset: 7416:998157a67421
user: Zoran Milinkovic zoran.milinkovic@ericsson.com
date: Fri Apr 01 14:23:50 2016 +0200
summary: imm: add support to the library for transactional safe read [#48]

changeset: 7417:fc7e103a87d6
user: Zoran Milinkovic zoran.milinkovic@ericsson.com
date: Fri Apr 01 14:24:34 2016 +0200
summary: imm: add support to IMM service for transactional safe read [#48]

changeset: 7418:edf2dcd3884e
tag: tip
user: Zoran Milinkovic zoran.milinkovic@ericsson.com
date: Fri Apr 01 14:25:16 2016 +0200
summary: imm: add tests for transactional safe read [#48]