AXML Transactions

1
AXML Transactions

• Debmalya Biswas

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.

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

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

5
Undo

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

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

7
Undo (contd.)

• AXML update operations (analogous to SQL and
  XQuery updates) can be divided into two parts
• the ltlocationgt 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.

8
Undo Delete Operation

• Delete operation
• ltaction type"delete"gt
• ltlocationgt
• Select p/citizenship from p in ATPList//player
  where p/name/lastnameFederer
• lt/locationgt
• lt/actiongt
• Compensating operation
• ltaction type"insert"gt
• ltdatagtltcitizenshipgtSwisslt/citizenshipgtlt/datagt
• ltlocationgt
• Select p/points/.. from p in ATPList//player
  where p/name/lastnameFederer
• lt/locationgt
• lt/actiongt
• where the ltlocationgt and ltdatagt of the
  compensating insert operation are the parent
  (/..) of the deleted node and the result of the
  ltlocationgt query of the delete operation
  respectively.

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

10
Undo Replace Operation (contd.)

• Replace operation
• ltaction type"replace"gt
• ltdatagtltcitizenshipgtUSAlt/citizenshipgtlt/datagt
• ltlocationgt
• Select p/citizenship from p in ATPList//player
  where p/name/lastnameNadal
• lt/locationgt
• lt/actiongt
• decomposes to
• ltaction type"delete"gt
• ltlocationgt
• Select p/citizenship from p in ATPList//player
  where p/name/lastnameNadal
• lt/locationgt
• lt/actiongt
• ltaction type"insert"gt
• ltdatagtltcitizenshipgtUSAlt/citizenshipgtlt/datagt
• ltlocationgt

11
Undo Replace Operation (contd.)

• Replace operation
• ltaction type"replace"gt
• ltdatagtltcitizenshipgtUSAlt/citizenshipgtlt/datagt
• ltlocationgt
• Select p/citizenship from p in ATPList//player
  where p/name/lastnameNadal
• lt/locationgt
• lt/actiongt
• Compensating operation
• ltaction type"delete"gt
• ltlocationgt
• Select p/citizenship from p in ATPList//player
  where p/name/lastnameNadal
• lt/locationgt
• lt/actiongt
• ltaction type"insert"gt
• ltdatagtltcitizenshipgtSwisslt/citizenshipgtlt/datagt
• ltlocationgt

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

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

14
Undo Query Operation (contd.)

• Query operation
• Select p/citizenship, p/grandslamswon from p in
  ATPList//player where p/name/lastnameFederer
• on the document
• lt?xml version"1.0" encoding"UTF-8"?gt
• ltATPList date"18042005"gt
• ltplayer rank1gt
• ltnamegtltfirstnamegtRogerlt/firstnamegtltlastnamegtFede
  rerlt/lastnamegtlt/namegt
• ltcitizenshipgtSwisslt/citizenshipgt
• ltaxmlsc mode"replace" serviceNameSpace"getPoi
  nts" serviceURL"" methodName"getPoints"gt
• ltaxmlparamsgt
• ltaxmlparam name"name"gtltaxmlvaluegtRoger
  Federerlt/axmlvaluegt
• lt/axmlparamsgt
• ltpointsgt475lt/pointsgt
• lt/axmlscgt
• ltaxmlsc mode"merge" serviceNameSpace"getGrand
  SlamsWonbyYear" serviceURL"" methodName"getGran
  dSlamsWonbyYear"gt
• ltaxmlparamsgt
• ltaxmlparam name"name"gtltaxmlvaluegtRoger
  Federerlt/axmlvaluegt
• ltaxmlparam name"year"gtltaxmlvaluegtyear
  (external value)lt/axmlvaluegt

15
Undo Query Operation (contd.)

• would lead to the materialization of the
  getGrandSlamsWonbyYear service call leading to
  the following document
• lt?xml version"1.0" encoding"UTF-8"?gtltATPList
  date"18042005"gt
• ltplayer rank1gt
• ltnamegtltfirstnamegtRogerlt/firstnamegtltlastnamegtFede
  rerlt/lastnamegtlt/namegt
• ltcitizenshipgtSwisslt/citizenshipgt
• ltaxmlsc mode"replace" serviceNameSpace"getPoi
  nts" serviceURL"" methodName"gt
• ltaxmlparamsgt
• ltaxmlparam name"name"gtltaxmlvaluegtRoger
  Federerlt/axmlvaluegt
• lt/axmlparamsgt
• ltpointsgt475lt/pointsgt
• lt/axmlscgt
• ltaxmlsc mode"merge" serviceNameSpace"getGrand
  SlamsWonbyYear" serviceURL"" methodName"gt
• ltaxmlparamsgt
• ltaxmlparam name"name"gtltaxmlvaluegtRoger
  Federerlt/axmlvaluegt
• ltaxmlparam name"year"gtltaxmlvaluegtyear
  (external value)lt/axmlvaluegt
• lt/axmlparamsgt
• ltgrandslamswon year"2004"gtA, W,
  Ult/grandslamswongt
• ltgrandslamswon year"2005"gtW,
  Ult/grandslamswongt
• lt/axmlscgt

16
Undo Order

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

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

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

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

20
Undo Order (example)
Synchronization issues due to nesting and
parallelism.
Transaction TA
APX
SX (TA)
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
SY (TA)
AP1
S3 (TA)
AP3
APZ
SZ (TA)
S3 (TA)
S4 (TA)
AP3
AP4
S5(TA)
AP5
AP5 fails.
AP
AP
Sequential invocation
Parallel invocation
21
Undo Order (example)
Transaction TA
APX
SX (TA)
APY
SY (TA)
AP1

• TCAY and TCAZ can be aborted in parallel.

S3 (TA)
AP3
APZ
SZ (TA)
S3 (TA)
S4 (TA)
AP3
AP4
S5(TA)
AP5
AP
AP
Sequential invocation
Parallel invocation
22
Undo Order (example)
Transaction TA
APX
SX (TA)
APY
SY (TA)
AP1

• TCA3 needs to be aborted before both TCAY and
  TCAZ.

S3 (TA)
AP3
APZ
SZ (TA)
S3 (TA)
S4 (TA)
AP3
AP4
S5(TA)
AP5
AP
AP
Sequential invocation
Parallel invocation
23
Undo Order (example)
Transaction TA
APX
SX (TA)
APY
SY (TA)
AP1

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

S3 (TA)
AP3
APZ
SZ (TA)
S3 (TA)
S4 (TA)
AP4
AP3
S5(TA)
AP5
AP
AP
Sequential invocation
Parallel invocation
24
Undo Order (example)
Transaction TA
APX
SX (TA)
APY

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

SY (TA)
AP1
S3 (TA)
AP3
APZ
SZ (TA)
S3 (TA)
S4 (TA)
AP3
AP4
S5(TA)
AP5
AP
AP
Sequential invocation
Parallel invocation
25
Recovery Protocol

• For a failure with respect to transaction TA, the
  failed peer sends an Abort TA message to its
  parent peer.

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

27
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
SY (TA)
SY(TA)
APY
APY
APX
APX
Sequential Invocation
Parallel Invocation
APZ
APZ
SZ (TA)
SZ (TA)
3. Abort TA
Abort TA
4. Confirm
28
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
SX (TA)
APX
AP
Abort TA
APY
SY (TA)
APZ
SZ (TA)
29
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.

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

31
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 e list-secd is aware of
  PRd.
• Both primary and secondary peers are subject to
  failure (arbitrary disconnection).
• Update messages are propagated with
  acknowledgement.

32
Eager Replication Guarantee

• With eager replication, an update on a document
  d_at_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.

33
Secondary Disconnection

• secondary AP1 e list-secd disconnects before
  receiving a propagated update of d_at_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 doesnt receive an acknowledgement from
  AP1 even after m retries, it deletes AP1 from
  list-secd.

34
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_at_AP1 with d_at_PRd.
• PRd adds AP1 to list-secd (if deleted).

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 deletes d from its repository and stops being
  a replicated peer of d.

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

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

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

39
Lazy Replication Approach
PRd
AP1
APn
AP2
AP4
AP3
Update propagation
PRd
AP1
APn
AP2
AP4
AP3
40

• THANKS
• Questions (if any ?)