AXML Transactions Debmalya Biswas. 16th AprSEIW 20072 Transactions A transaction can be considered...

AXML Transactions

Debmalya Biswas

16th Apr SEIW 2007 2

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.


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).


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.


Undo

We consider compensation like undo operations and show how they can be constructed dynamically.


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.


Undo (contd.)

AXML update operations (analogous to SQL and XQuery updates) can be divided into two parts:

1) the <location> query to locate the target nodes and 2) 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.


Undo – Delete OperationDelete 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.


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.


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>


</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>


Undo – Replace Operation (contd.)

Replace operation:

<action type="replace"><data><citizenship>USA</citizenship></data><location>


</action>

Compensating operation:

<action type="delete"><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>


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).


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 pre-defined statically (has to be constructed dynamically).



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>



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>”.


Undo Order

For sequential invocations, we know that their corresponding aborts need to be performed in reverse order of the original execution order.


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).


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.


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.


Undo Order (example)

SY (TA)

S3 (TA)

AP1

APX

AP3

APY

AP5

S5(TA)

Transaction TA

SX (TA)

SZ (TA)APZ

S3 (TA)

AP3

APAP Sequential invocation

Parallel invocation

S4 (TA)AP4

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.

AP5 fails.

Synchronization issues due to nesting and parallelism.



SY (TA)

S3 (TA)

AP1

APX

AP3

APY

AP5

S5(TA)

Transaction TA

SX (TA)

SZ (TA)APZ

S3 (TA)

AP3


Parallel invocation

S4 (TA)AP4

TCAY and TCAZ can be aborted in parallel.



SY (TA)

S3 (TA)

AP1

APX

AP3

APY

AP5

S5(TA)

Transaction TA

SX (TA)

SZ (TA)APZ

S3 (TA)

AP3


Parallel invocation

S4 (TA)AP4

TCA3 needs to be aborted before both TCAY and TCAZ.



SY (TA)

S3 (TA)

AP1

APX

AP3

APY

AP5

S5(TA)

Transaction TA

SX (TA)

SZ (TA)APZ

S3 (TA)

AP3


Parallel invocation

S4 (TA)AP4

TCA4 needs to be aborted before TCA3, TCAY and TCAZ.



SY (TA)

S3 (TA)

AP1

APX

AP3

APY

AP5

S5(TA)

Transaction TA

SX (TA)

SZ (TA)APZ

S3 (TA)

AP3


Parallel invocation

S4 (TA)AP4

Finally, TCA4, TCA3, TCAY and TCAZ need to be aborted before TCAX.


Recovery Protocol

For a failure with respect to transaction TA, the failed peer sends an

“Abort TA” message to its parent peer.


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.


2. Confirm

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.

SY(TA)

SZ (TA)

APY

1. Abort TA

3. Abort TA

APX

4. Confirm

APZ

SY (TA)

SZ (TA)

APY

APX

APZ

Abort TA

Abort TA

Sequential Invocation

Parallel Invocation


Confirm

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).

SX (TA)

SY (TA)

APX

APY

Abort TA

SZ (TA)APZ

AP


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.


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.


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.


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.


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.


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).



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.



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.


Lazy ReplicationUpdate 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.


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.


Lazy Replication ApproachPRdAP1

AP2 AP4

APn

AP3

Update propagation

PRdAP1

AP2 AP4

APn

AP3


THANKS&

Questions (if any … )

AXML Transactions Debmalya Biswas. 16th AprSEIW 20072 Transactions A transaction can be considered...

Documents

Transcript of AXML Transactions Debmalya Biswas. 16th AprSEIW 20072 Transactions A transaction can be considered...