AXML Transactions
Debmalya Biswas
Transactions
A transaction can be considered as a group of operations encapsulated by the
operations Begin and Commit/Abort having the following properties:
Atomicity (A), Consistency (C), Isolation (I), Durability (D).

Atomicity: Either all the operations are executed or none of them are executed.
16th Apr
SEIW 2007
2
Transactional Unit
The possible operations on AXML documents are query, replace, insert and delete
(update operations with action types “replace”, “insert” and “delete”).
We consider the transactional unit as a set of update/query operations (services).
16th Apr
SEIW 2007
3
Infrastructure



Each AXML peer has an integrated Transaction Manager and Log Manager.
The peer at which a transaction TA is originally submitted is referred to as its
origin peer. Peers whose services are invoked while processing TA are referred
to as the participant peers.
On submission of a subtransaction of TA at peer AP1, the peer creates a
transaction context TCA1. The transaction context encapsulates all the
information required for concurrency control, commit and recovery of the
corresponding transaction.
16th Apr
SEIW 2007
4
Undo
We consider compensation like undo operations and show how they can
be constructed dynamically.
16th Apr
SEIW 2007
5
Undo - Compensation


A compensating operation is responsible for semantically undoing the effects of
the original operation. For example, the compensation of “Book Hotel” is “Cancel
Hotel Booking”.
Usually, the compensation handlers for a service call are pre-defined statically
on the lines of fault (exception) handlers.
However, static definition of compensation handlers is not feasible for
AXML, especially, for AXML query operations.
16th Apr
SEIW 2007
6
Undo (contd.)
AXML update operations (analogous to SQL and XQuery updates) can be divided
into two parts:
1)
2)
the <location> query to locate the target nodes and
the actual update actions.
The data (nodes) required for compensation cannot be predicted in advance and
would need to be read from the log at run-time.
16th Apr
SEIW 2007
7
Undo – Delete Operation
Delete operation:
<action type="delete">
<location>
Select p/citizenship from p in ATPList//player where p/name/lastname=Federer;
</location>
</action>
Compensating operation:
<action type="insert">
<data><citizenship>Swiss</citizenship></data>
<location>
Select p/points/.. from p in ATPList//player where p/name/lastname=Federer;
</location>
</action>
where the <location> and <data> of the compensating insert operation are the
parent (/..) of the deleted node and the result of the <location> query of the
delete operation respectively.
16th Apr
SEIW 2007
8
Undo – Insert & Replace
Operations


For AXML insert operations, we assume that the operation returns the (unique)
ID of the inserted node. As such, the compensating operation (for the insert
operation) is a delete operation to delete the node having the corresponding ID.
An AXML replace operation is usually implemented as a combination of a delete
and insert operation, i.e., delete the node to be replaced followed by insertion of
a node (having the updated value) at the same position.
16th Apr
SEIW 2007
9
Undo – Replace Operation
(contd.)
Replace operation:
<action type="replace">
<data><citizenship>USA</citizenship></data>
<location>
Select p/citizenship from p in ATPList//player where p/name/lastname=Nadal;
</location>
</action>
decomposes to:
<action type="delete">
<location>
Select p/citizenship from p in ATPList//player where p/name/lastname=Nadal;
</location>
</action>
<action type="insert">
<data><citizenship>USA</citizenship></data>
<location>
Select p/citizenship/.. from p in ATPList//player where p/name/lastname=Nadal;
</location>
</action>
16th Apr
SEIW 2007
10
Undo – Replace Operation
(contd.)
Replace operation:
<action type="replace">
<data><citizenship>USA</citizenship></data>
<location>
Select p/citizenship from p in ATPList//player where p/name/lastname=Nadal;
</location>
</action>
Compensating operation:
<action type="delete">
<location>
Select p/citizenship from p in ATPList//player where p/name/lastname=Nadal;
</location>
</action>
<action type="insert">
<data><citizenship>Swiss</citizenship></data>
<location>
Select p/citizenship/.. from p in ATPList//player where p/name/lastname=Nadal;
</location>
</action>
16th Apr
SEIW 2007
11
Undo – Query Operation

Traditionally, query operations do not need to be compensated as they do not
modify data.
However, AXML queries, due to the possibility of service call
materializations, are capable of modifying the AXML document, e.g., insertion of
the result nodes (and deletion of the previous result nodes).
16th Apr
SEIW 2007
12
Undo – Query Operation
(contd.)

There are two possible modes for AXML query evaluation: lazy and eager. Of the
two, lazy evaluation is the preferred mode, and implies that only those
embedded service calls are materialized whose results are required for
evaluating the query.
As the actual set of embedded service calls materialized is determined
only at run-time, the compensating operation for an AXML query cannot be predefined statically (has to be constructed dynamically).
16th Apr
SEIW 2007
13
Undo – Query Operation
(contd.)
Query operation:
Select p/citizenship, p/grandslamswon from p in ATPList//player where p/name/lastname=Federer
on the document
<?xml version="1.0" encoding="UTF-8"?>
<ATPList date="18042005">
<player rank=1>
<name><firstname>Roger</firstname><lastname>Federer</lastname></name>
<citizenship>Swiss</citizenship>
<axml:sc mode="replace" serviceNameSpace="getPoints" serviceURL="…" methodName="getPoints">
<axml:params>
<axml:param name="name"><axml:value>Roger Federer</axml:value>
</axml:params>
<points>475</points>
</axml:sc>
<axml:sc mode="merge" serviceNameSpace="getGrandSlamsWonbyYear" serviceURL="…"
methodName="getGrandSlamsWonbyYear">
<axml:params>
<axml:param name="name"><axml:value>Roger Federer</axml:value>
<axml:param name="year"><axml:value>$year (external value)</axml:value>
</axml:params>
<grandslamswon year="2004">A, W, U</grandslamswon>
</axml:sc>
</player>
…
</ATPList>
16th Apr
SEIW 2007
14
Undo – Query Operation
(contd.)
would lead to the materialization of the “getGrandSlamsWonbyYear” service call leading to the following document
<?xml version="1.0" encoding="UTF-8"?><ATPList date="18042005">
<player rank=1>
<name><firstname>Roger</firstname><lastname>Federer</lastname></name>
<citizenship>Swiss</citizenship>
<axml:sc mode="replace" serviceNameSpace="getPoints" serviceURL="…" methodName=“…">
<axml:params>
<axml:param name="name"><axml:value>Roger Federer</axml:value>
</axml:params>
<points>475</points>
</axml:sc>
<axml:sc mode="merge" serviceNameSpace="getGrandSlamsWonbyYear" serviceURL="…" methodName=“…">
<axml:params>
<axml:param name="name"><axml:value>Roger Federer</axml:value>
<axml:param name="year"><axml:value>$year (external value)</axml:value>
</axml:params>
<grandslamswon year="2004">A, W, U</grandslamswon>
<grandslamswon year="2005">W, U</grandslamswon>
</axml:sc>
</player>
…</ATPList>
Thus, the compensation for the above query operation is a delete operation to delete the node “<grandslamswon year="2005">W,
U</grandslamswon>”.
16th Apr
SEIW 2007
15
Undo Order
For sequential invocations, we know that their corresponding aborts need
to be performed in reverse order of the original execution order.
16th Apr
SEIW 2007
16
Undo Order (Parallel)
Operations within an AXML transaction can be invoked in parallel, e.g.,
simultaneous materialization of embedded service calls as part of a query
evaluation.
For parallel invocations, their aborts can also be performed in parallel (to improve
performance).
This aspect is often ignored by current systems, e.g., BPEL where the default
compensation is sequential, although, BPEL supports parallelism for forward
activities (the flow operator).
16th Apr
SEIW 2007
17
Undo Order (Nested)
An AXML transaction can nested:


Local: The service call parameters may themselves be defined as service
calls. Analogously, a service invocation may return another service call as its
result leading to a nested invocation of service calls.
Distributed: Invocation of a service SX of peer AP2 by peer AP1 may require
the peer AP2 to invoke another service SY of peer AP3 while executing SX
leading to a nested invocation of service calls across multiple peers.
For nested transactions, all children subtransactions need to have been undone
before the parent subtransaction can be undone.
16th Apr
SEIW 2007
18
Undo Order (Rules)
To summarize:
Let TCA1-1 denote the abort of TCA1, that is, the transaction encapsulating the (undo)
operations needed to abort TCA1. Then,,

Rule 1. If a pair of children subtransactions TCA1 and TCA2 were invoked in
sequence, that is, TCA1 → TCA2, then TCA2-1 → TCA1-1.

Rule 2. If they were invoked in parallel, that is, TCA1 || TCA2, then TCA1-1 ||
TCA2-1.

Rule 3. If TCA1 is the parent subtransaction of TCA2, then TCA2-1 should occur
before TCA1-1.
16th Apr
SEIW 2007
19
Undo Order (example)
Synchronization issues due to nesting and parallelism.
APX
AP5 fails while processing the service S5
(subtransaction TCA5) .
As such, TCAX, TCAY, TCAZ, TCA3 and TCA4, all of
them need to be aborted, but their
ordering is important.
APY
APZ
AP4
S4 (TA)
AP5 fails.
Parallel
invocation
16th Apr
SEIW 2007
Transaction
TA
SX (TA)
SY (TA)
AP1
AP3
S3 (TA)
Sequential
invocation
AP
SZ (TA)
S3 (TA)
AP3
AP5
AP
S5(TA)
20
Undo Order (example)
APX

APY
TCAY and TCAZ can be aborted in
parallel.
APZ
AP4
S4 (TA)
16th Apr
SEIW 2007
SX (TA)
SY (TA)
AP1
AP3
S3 (TA)
Sequential
invocation
AP
SZ (TA)
S3 (TA)
AP3
AP5
Parallel
invocation
Transaction
TA
AP
S5(TA)
21
Undo Order (example)
APX

APY
TCA3 needs to be aborted before both
TCAY and TCAZ.
APZ
AP4
S4 (TA)
16th Apr
SEIW 2007
SX (TA)
SY (TA)
AP1
AP3
S3 (TA)
Sequential
invocation
AP
SZ (TA)
S3 (TA)
AP3
AP5
Parallel
invocation
Transaction
TA
AP
S5(TA)
22
Undo Order (example)
APX

APY
TCA4 needs to be aborted before TCA3,
TCAY and TCAZ.
APZ
AP4
S4 (TA)
16th Apr
SEIW 2007
SX (TA)
SY (TA)
AP1
AP3
S3 (TA)
Sequential
invocation
AP
SZ (TA)
S3 (TA)
AP3
AP5
Parallel
invocation
Transaction
TA
AP
S5(TA)
23
Undo Order (example)
APX

APY
Finally, TCA4, TCA3, TCAY and TCAZ need
to be aborted before TCAX.
APZ
AP4
S4 (TA)
16th Apr
SEIW 2007
SX (TA)
SY (TA)
AP1
AP3
S3 (TA)
Sequential
invocation
AP
SZ (TA)
S3 (TA)
AP3
AP5
Parallel
invocation
Transaction
TA
AP
S5(TA)
24
Recovery Protocol

For a failure with respect to transaction TA, the failed peer sends an “Abort
TA” message to its parent peer.
16th Apr
SEIW 2007
25
Recovery Protocol (contd.)

A parent APX, on receiving the “Abort TA” message from its child peer, does
the following:
1. Wait for any currently executing siblings of the failed subtransaction to commit.
16th Apr
SEIW 2007
26
Recovery Protocol (contd.)

A parent APX, on receiving the “Abort TA” message from its child peer, does
the following:
2. For all its committed children subtransactions of TA (if any), APX determines the
invocation order (sequential/parallel) and sends the “Abort TA” messages in
accordance with Rules 1/2.
1. Abort TA
Abort TA
2. Confirm
APY
Sequential
Invocation
SY(TA)
APY
APX
APZ
Parallel Invocation
APX
APZ
SZ (TA)
3. Abort TA
SZ (TA)
Abort TA
4. Confirm
16th Apr
SY (TA)
SEIW 2007
27
Recovery Protocol (contd.)

A parent APX, on receiving the “Abort TA” message from its child peer, does
the following:
3. On receiving the abort confirmation from all its children peers, APX sends an
“Abort TA” message to its parent peer (if any).
Confirm
APX
SX (TA)
APY SY (TA)
APZ
16th Apr
AP
Abort TA
SZ (TA)
SEIW 2007
28
Nested Recovery Protocol
(contd.)


A child APY, on receiving the “Abort TA” message from its parent peer,
determines the abort order for its children subtransactions of TA (if any) and
sends the “Abort TA” messages, in accordance with Rules 1 and 2.
As before, on receiving the abort confirmation from all its children peers, APY
sends an abort confirmation to its parent peer.
Rule 3 implicitly holds as a result of the peers waiting for all their children
peers to confirm abortion, before sending the “Abort TA” messages or
confirming abortion to their own parents.
16th Apr
SEIW 2007
29
Replication
More than one copy of an AXML document d on the peers AP1, AP2, · · · , APn. The
peers AP1, AP2, · · · , APn are referred to as the replicated peers of d.
Objective:
Given a replicated system with a fixed storage/replication strategy and possibility of
failure, study the replication guarantees that can be provided.
16th Apr
SEIW 2007
30
Primary-Secondary
Configuration





A peer, among the replicated peers of a document d, is designated as the
primary of d (PRd), and the remaining are referred to as secondaries of d.
An update on a document d can only occur at PRd while a query based on d can
be answered by any of the replicated peers of d.
We assume that a primary PRd retains a list of the secondaries of d, referred to
as list−secd. Further, each peer AP ε list−secd is aware of PRd.
Both primary and secondary peers are subject to failure (arbitrary
disconnection).
Update messages are propagated with acknowledgement.
16th Apr
SEIW 2007
31
Eager Replication Guarantee
With eager replication, an update on a document d@AP as part of transaction T, is
propagated to the other replicated peers of d within the same transaction T.
At any point of time, evaluation of an AXML query q based on document d
produces the same result, irrespective of the (replicated) peer (of d)
where q was evaluated.
16th Apr
SEIW 2007
32
Secondary Disconnection
secondary AP1 ε list−secd disconnects before receiving a propagated
update of d@AP

As a result, PRd would not receive an acknowledgement from AP1.

PRd follows a timeout mechanism: retries the send after t secs.

if PRd doesn’t receive an acknowledgement from AP1 even after m retries, it
deletes AP1 from list-secd.
16th Apr
SEIW 2007
33
Secondary Reconnection
peer AP1, on reconnecting, does the following (before performing any
updates or answering queries):
For each hosted document d, if AP1 was a secondary of d before disconnection, then
AP1 tries to contact PRd. If successful:

AP1 synchronizes the state of d@AP1 with d@PRd.

PRd adds AP1 to list-secd (if deleted).
16th Apr
SEIW 2007
34
Secondary Reconnection
For each hosted tree d, if AP1 was a secondary of d before disconnection, then AP1
tries to contact PRd. If PRd has also disconnected:

AP1 deletes d from its repository and stops being a replicated peer of d.
16th Apr
SEIW 2007
35
Secondary Reconnection
For each hosted tree d, if AP1 was a secondary of d before disconnection, then AP1
tries to contact PRd. If PRd has also disconnected:



AP1 initiates a search (flooding) of the P2P network to locate the replicated
peers of d.
Synchronize the state of d on the replicated peers and execute a leader election
algorithm.
The elected leader becomes the new primary PRd and its list-secd is assigned the
list of replicated peers.
16th Apr
SEIW 2007
36
Lazy Replication
Update propagation is not performed as part of the expression evaluation
transaction. Rather, the updates are propagated “as and when” convenient after
the corresponding transaction has committed at the primary.
This allows the primary to proceed with the next expression evaluation (transaction)
without having to wait for the corresponding secondaries’ acknowledgments,
increasing the system throughput.
Limitation:
For an update on a document d, if PRd disconnects before the update has been
propagated to any of the peers in list−secd, then the update is lost forever.
16th Apr
SEIW 2007
37
Lazy Replication Guarantee
Guarantee:
For a pair of propagated updates u1 and u2 on document d at secondary peers AP1
≠ AP2, if u1 (u2) occurs before u2 (u1) at AP1, then u1 (u2) also occurs before u2
(u1) at AP2.
Intuitively, updates may not occur at the same time on its secondaries, however
they occur in the same order. This is particularly significant for programs which
rely on a stream of inputs, e.g., AXML continuous services, (user) session
guarantees.
16th Apr
SEIW 2007
38
Lazy Replication Approach
AP1
PRd
AP2
APn
AP3
AP4
Update propagation
AP1
PRd
AP2
16th Apr
AP3
APn
AP4
SEIW 2007
39
THANKS
&
Questions (if any … )
16th Apr
SEIW 2007
40