- Description has changed:
Diff:
~~~~
--- old
+++ new
@@ -14,10 +14,21 @@
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/transactions needs to read (and have unchanged or only
+the ccb/transaction needs to read (and have unchanged or only
changed by the same ccb/transaction) untill the ccb/transaction
-terminates.
+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
@@ -45,20 +56,24 @@
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 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.
+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 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.
+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
@@ -89,14 +104,9 @@
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 ?
+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.
~~~~
---
** [tickets:#48] IMM: Support for transactionally safe reads**
**Status:** accepted
**Milestone:** 5.0
**Created:** Wed May 08, 2013 07:48 AM UTC by Anders Bjornerstedt
**Last Updated:** Wed Sep 30, 2015 02:50 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.
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.
---
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.------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
