- **status**: assigned --> accepted
- **Milestone**: future --> 4.7-Tentative
---
** [tickets:#48] IMM: Support for transactionally safe reads**
**Status:** accepted
**Milestone:** 4.7-Tentative
**Created:** Wed May 08, 2013 07:48 AM UTC by Anders Bjornerstedt
**Last Updated:** Wed Feb 25, 2015 12:22 PM UTC
**Owner:** 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.
The 'read-set' for a ccb/transaction is the set of objects that
the ccb/transactions needs to read (and have unchanged or only
changed by the same ccb/transaction) untill the ccb/transaction
terminates.
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,
const SaNameT *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.
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 by other Ccbs.
Another Ccb trying to write lock this object when this
ccb has a read-lock will fail and have to wait at least until
after this ccb is terminated.
A safe read on an object that is already write locked by the same
Ccb will succeed, but not change the lock-type and will provide the
current value of the object in the context of the CCB. 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
API. This could be provided as a separate enhancement.
-------------------------------------------------------------------
One issue that has not been settled in relation to this enhancement is
whether admin-owner has to be set for the objects being safe-read.
My opinion is that for a purely safe reading CCB, admin-owner should not have
to be set.
But for a CCB that both safe-reads and writes (create/delete/modify) it at
least makes
sense to set admin-owner, possibly automatically. The main question is if
admin-owner can
not be set, becasue it is already set to a different admin-owner, then should
this prevent the progress of this CCB ?
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
