- **status**: fixed --> accepted
- **Comment**:
Add support for enabling/disabling the new features tracked by this ticket
based on the opensafImmNostdFlags bit 5 for upgrades to OpenSAF 4.5
---
** [tickets:#798] IMM: Support for explicit ccb-validate and explicit
ccb-abort**
**Status:** accepted
**Milestone:** 4.5.FC
**Created:** Thu Feb 27, 2014 03:47 PM UTC by Anders Bjornerstedt
**Last Updated:** Mon Apr 28, 2014 03:20 PM UTC
**Owner:** Anders Bjornerstedt
We propose two new ccb-related functions to be added to the IMM OM interface.
Neither of these two functions have any impact on the OI interface.
(1) Support for explicit validation separate from saImmOmCcbApply()
The function:
SaAisErrorT saImmOmCcbValidate(SaImmCcbHandeT ccbHandle);
Executes the validation protocol towards the OIs for the current CCB linked to
the ccbHandle, but does not apply/commit the CCB even if validation succeeds.
If the saImmOmValidate function returns SA_AIS_OK then the validation succeeded
for that CCB. But the user now has the option to either commit/apply the CCB
using saImmOmCcbApply() or to abort the CCB using either saImmOmCcbFinalize
or saImmOmCcbAbort (explicit abort function explained below).
If the user decides to apply a CCB that has been successfully validated, then
saImmOmCcbApply() will try to commit/apply the CCB. Validation will NOT be
performed again here by the apply down-call when the CCB is already validated.
The apply could still fail due to resource reasons, but not due to failure in
validation.
But the user may also decide to abort the CCB, despite that it validated with
success. This is the new option provided by ccbValidate, the option to abort
the current CCB despite that it validated with success.
There are two reasons for providing this explicit validate function broken out
from ccbApply.
The first reason is that some GUI level tools may want to support incremental
buildup of a CCB, where the human user is "hesitant" and wants to pre-check if
the current contents of the CCB validates or not, before continuing to add
more operations. The validate downcall allows the tool to provide such an
option, but if more operations are to be added to the CCB, then the current IMM
CCB neds to be aborted and all operations replayed to re-create the CCB under
a new ccb-id (new transaction). Such a replay is *likely* to succeed and
*likely* to validate again but not *guaranteed* to validate. It may not
validate if some other CCB has been applied in the gap, changing the base of
the validation. The replay is necessary because the OIs are not prepared to
get the same validation callbacks again for the same CCB-id.
The second reason for providing the broken out validate function is for the IMM
to provide something that comes close to an open two-phase commit API. This is
useful for providing transactions/ccbs that span not just the IMM but also
some additional external DBMS. This is not true X/Open XA, but if the other
DBMS provides true open 2PC then full transactional atomicity can be obtained
by using validate to minimize risk for abort in the IMM, then a corresponding
full open prepare in the other DBMS, then apply towards IMM letting the IMM
be the transaction coordinator. If the commit in the IMM fails then the global
transaction is aborted, if the commit succeeds in the IMM then the other
database is obliged to succeed in its commit.
--------------------------------------------------------------------
(2) Support for explicit abort() of the current ccb linked to the ccbHandle.
The function:
SaAisErrorT saImmOmCcbAbort(SaImmCcbHandeT ccbHandle);
Allows the OM user to explicitly abort the current CCB (ccb-id) linked to
the ccbHandle, without closing the handle. This is not an essential function
but it reduces the unnecessary overhead of closing and opening a cchHandle
when only an abort is desired.
Using the saImmOmAbort() would be obvious for a client intending to replay
a CCB that has been validated. To replay a CCB and allow new additions
of operations beyond what was previously validated, the current ccb needs
to be aborted, the previous operations replayed, then new operations added.
The explicit abort here avoids closing and opening the handle.
The saImmOmCcbAbort also makes the ccb-om API symetric. The user may explicitly
decide to abort a ccb, then continue to build a new (chained) ccb(id) in exactly
the way that is currently allowed after a successfull saImmOmCcbApply.
An saImmOmCcbApply that fails with SA_AIS_ERR_FAILED_OPEATION previously meant
that the handle could no longer be used. Now the handle can be used to create
new ccb(id)s if an explicit saImmOmCcbAbort() is invoked to confirm the
recognition of the abort by the OM user.
---
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.------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
