AXML Transactions Debmalya Biswas

16th AprSEIW 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 AprSEIW 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 AprSEIW Infrastructure Each AXML peer has an integrated Transaction Manager and Log Manager. The peer at which a transaction T A is originally submitted is referred to as its origin peer. Peers whose services are invoked while processing T A are referred to as the participant peers. On submission of a subtransaction of T A at peer AP 1, the peer creates a transaction context TC A1. The transaction context encapsulates all the information required for concurrency control, commit and recovery of the corresponding transaction.

16th AprSEIW Undo We consider compensation like undo operations and show how they can be constructed dynamically.

16th AprSEIW 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 AprSEIW Undo (contd.) AXML update operations (analogous to SQL and XQuery updates) can be divided into two parts: 1) the 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.

16th AprSEIW Undo – Delete Operation Delete operation: Select p/citizenship from p in ATPList//player where p/name/lastname=Federer; Compensating operation: Swiss Select p/points/.. from p in ATPList//player where p/name/lastname=Federer; where the and of the compensating insert operation are the parent (/..) of the deleted node and the result of the query of the delete operation respectively.

16th AprSEIW 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 AprSEIW Undo – Replace Operation (contd.) Replace operation: USA Select p/citizenship from p in ATPList//player where p/name/lastname=Nadal; decomposes to: Select p/citizenship from p in ATPList//player where p/name/lastname=Nadal; USA Select p/citizenship/.. from p in ATPList//player where p/name/lastname=Nadal;

16th AprSEIW Undo – Replace Operation (contd.) Replace operation: USA Select p/citizenship from p in ATPList//player where p/name/lastname=Nadal; Compensating operation: Select p/citizenship from p in ATPList//player where p/name/lastname=Nadal; Swiss Select p/citizenship/.. from p in ATPList//player where p/name/lastname=Nadal;

16th AprSEIW 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 AprSEIW 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).

16th AprSEIW Undo – Query Operation (contd.) Query operation: Select p/citizenship, p/grandslamswon from p in ATPList//player where p/name/lastname=Federer on the document Roger Federer Swiss Roger Federer 475 Roger Federer $year (external value) A, W, U …

16th AprSEIW Undo – Query Operation (contd.) would lead to the materialization of the “getGrandSlamsWonbyYear” service call leading to the following document Roger Federer Swiss Roger Federer 475 Roger Federer $year (external value) A, W, U W, U … Thus, the compensation for the above query operation is a delete operation to delete the node “ W, U ”.

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

16th AprSEIW 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 AprSEIW 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 S X of peer AP 2 by peer AP 1 may require the peer AP 2 to invoke another service S Y of peer AP 3 while executing S X 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 AprSEIW Undo Order (Rules) To summarize: Let TC A1 -1 denote the abort of TC A1, that is, the transaction encapsulating the (undo) operations needed to abort TC A1. Then,, Rule 1. If a pair of children subtransactions TC A1 and TC A2 were invoked in sequence, that is, TC A1 → TC A2, then TC A2 -1 → TC A1 -1. Rule 2. If they were invoked in parallel, that is, TC A1 || TC A2, then TC A1 -1 || TC A2 -1. Rule 3. If TC A1 is the parent subtransaction of TC A2, then TC A2 -1 should occur before TC A1 -1.

16th AprSEIW Undo Order (example) S Y (T A ) S 3 (T A ) AP 1 AP X AP 3 AP Y AP 5 S 5 (T A ) Transaction T A S X (T A ) S Z (T A ) AP Z S 3 (T A ) AP 3 AP Sequential invocation Parallel invocation S 4 (T A ) AP 4 AP 5 fails while processing the service S 5 (subtransaction TC A5 ). As such, TC AX, TC AY, TC AZ, TC A3 and TC A4, all of them need to be aborted, but their ordering is important. AP 5 fails. Synchronization issues due to nesting and parallelism.

16th AprSEIW Undo Order (example) S Y (T A ) S 3 (T A ) AP 1 AP X AP 3 AP Y AP 5 S 5 (T A ) Transaction T A S X (T A ) S Z (T A ) AP Z S 3 (T A ) AP 3 AP Sequential invocation Parallel invocation S 4 (T A ) AP 4 TC AY and TC AZ can be aborted in parallel.

16th AprSEIW Undo Order (example) S Y (T A ) S 3 (T A ) AP 1 AP X AP 3 AP Y AP 5 S 5 (T A ) Transaction T A S X (T A ) S Z (T A ) AP Z S 3 (T A ) AP 3 AP Sequential invocation Parallel invocation S 4 (T A ) AP 4 TC A3 needs to be aborted before both TC AY and TC AZ.

16th AprSEIW Undo Order (example) S Y (T A ) S 3 (T A ) AP 1 AP X AP 3 AP Y AP 5 S 5 (T A ) Transaction T A S X (T A ) S Z (T A ) AP Z S 3 (T A ) AP 3 AP Sequential invocation Parallel invocation S 4 (T A ) AP 4 TC A4 needs to be aborted before TC A3, TC AY and TC AZ.

16th AprSEIW Undo Order (example) S Y (T A ) S 3 (T A ) AP 1 AP X AP 3 AP Y AP 5 S 5 (T A ) Transaction T A S X (T A ) S Z (T A ) AP Z S 3 (T A ) AP 3 AP Sequential invocation Parallel invocation S 4 (T A ) AP 4 Finally, TC A4, TC A3, TC AY and TC AZ need to be aborted before TC AX.

16th AprSEIW Recovery Protocol For a failure with respect to transaction T A, the failed peer sends an “Abort T A ” message to its parent peer.

16th AprSEIW Recovery Protocol (contd.) A parent AP X, on receiving the “Abort T A ” message from its child peer, does the following: 1. Wait for any currently executing siblings of the failed subtransaction to commit.

16th AprSEIW Confirm Recovery Protocol (contd.) A parent AP X, on receiving the “Abort T A ” message from its child peer, does the following: 2. For all its committed children subtransactions of T A (if any), AP X determines the invocation order (sequential/parallel) and sends the “Abort T A ” messages in accordance with Rules 1/2. S Y (T A ) S Z (T A ) AP Y 1. Abort T A 3. Abort T A AP X 4. Confirm AP Z S Y (T A ) S Z (T A ) AP Y AP X AP Z Abort T A Sequential Invocation Parallel Invocation

16th AprSEIW Confirm Recovery Protocol (contd.) A parent AP X, on receiving the “Abort T A ” message from its child peer, does the following: 3. On receiving the abort confirmation from all its children peers, AP X sends an “Abort T A ” message to its parent peer (if any). S X (T A ) S Y (T A ) AP X AP Y Abort T A S Z (T A ) AP Z AP

16th AprSEIW Nested Recovery Protocol (contd.) A child AP Y, on receiving the “Abort T A ” message from its parent peer, determines the abort order for its children subtransactions of T A (if any) and sends the “Abort T A ” messages, in accordance with Rules 1 and 2. As before, on receiving the abort confirmation from all its children peers, AP Y 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 T A ” messages or confirming abortion to their own parents.

16th AprSEIW Replication More than one copy of an AXML document d on the peers AP 1, AP 2, · · ·, AP n. The peers AP 1, AP 2, · · ·, AP n 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 AprSEIW Primary-Secondary Configuration A peer, among the replicated peers of a document d, is designated as the primary of d (PR d ), and the remaining are referred to as secondaries of d. An update on a document d can only occur at PR d while a query based on d can be answered by any of the replicated peers of d. We assume that a primary PR d retains a list of the secondaries of d, referred to as list−sec d. Further, each peer AP ε list−sec d is aware of PR d. Both primary and secondary peers are subject to failure (arbitrary disconnection). Update messages are propagated with acknowledgement.

16th AprSEIW Eager Replication Guarantee With eager replication, an update on a document 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 AprSEIW Secondary Disconnection secondary AP 1 ε list−sec d disconnects before receiving a propagated update of As a result, PR d would not receive an acknowledgement from AP 1. PR d follows a timeout mechanism: retries the send after t secs. if PR d doesn’t receive an acknowledgement from AP 1 even after m retries, it deletes AP 1 from list-sec d.

16th AprSEIW Secondary Reconnection peer AP 1, on reconnecting, does the following (before performing any updates or answering queries): For each hosted document d, if AP 1 was a secondary of d before disconnection, then AP 1 tries to contact PR d. If successful: AP 1 synchronizes the state of 1 with d. PR d adds AP 1 to list-sec d (if deleted).

16th AprSEIW Secondary Reconnection For each hosted tree d, if AP 1 was a secondary of d before disconnection, then AP 1 tries to contact PR d. If PR d has also disconnected: AP 1 deletes d from its repository and stops being a replicated peer of d.

16th AprSEIW Secondary Reconnection For each hosted tree d, if AP 1 was a secondary of d before disconnection, then AP 1 tries to contact PR d. If PR d has also disconnected: AP 1 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 PR d and its list-sec d is assigned the list of replicated peers.

16th AprSEIW 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 PR d disconnects before the update has been propagated to any of the peers in list−sec d, then the update is lost forever.

16th AprSEIW Lazy Replication Guarantee Guarantee: For a pair of propagated updates u 1 and u 2 on document d at secondary peers AP 1 ≠ AP 2, if u 1 (u 2 ) occurs before u 2 (u 1 ) at AP 1, then u 1 (u 2 ) also occurs before u 2 (u 1 ) at AP 2. 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 AprSEIW Lazy Replication Approach PR d AP 1 AP 2 AP 4 AP n AP 3 Update propagation PR d AP 1 AP 2 AP 4 AP n AP 3

16th AprSEIW THANKS & Questions (if any … )