Contest of XML Lock Protocols

1
Contest of XML Lock Protocols
Michael P. Haustein, SAP AG Theo Härder, Univ.
of Kaiserslautern Konstantin Luttenberger,
Fraunhofer Institute IESE haerder_at_informatik.uni-
kl.de
32nd Int. Conf. on Very Large Data Bases VLDB
2006 12-15 September 2006, Seoul, Korea
2
Outline

• Key ideas of 2 groups of competing XML lock
  protocols
• Doc2PL and followers
• Node2PL, NO2PL, OO2PL
• multi-granularity locking (MGL group)
• RIX, RIX, IRIX, IRIX, URIX
• Our own protocols taDOM group
• taDOM2 base protocol for DOM2
• lock conversion
• optimization to taDOM2
• not considered taDOM3, taDOM3
• Introduction to XTC
• identifying nodes
• meta-synchronization
• Performance evaluation
• taMIX framework
• transaction types of the Banking benchmark
• measurements and comparison
• Conclusions and outlook

3
DOM Storage Model

• XML documentlt?xml version"1.0"?gtltbibgt ltbook
  year"2004" id"book1"gt lttitlegtThe
  Titlelt/titlegt ltauthorgt
  ltlastgtLastnamelt/lastgt ltfirstgtFirstnamelt/firs
  tgt lt/authorgt ltpricegt49.99lt/pricegt
  lt/bookgtlt/bibgt

DOM API (gt 20 ops)

• Navigation
• getFirst/LastChild
• getNextSibling
• getPreviousSibling
• getAttributes/Value

• Modification
• appendChild
• insertBefore
• removeChild

• Query
• getElementById
• getChildNodes

4
Doc2PL and its Followers

• Basic assumption Traversal from root to context
  node
• Sample of operations
• nthP retrieves the nth child of C
• nthM retrieves the nth child (backw.)
• insA inserts a new node after C
• insB inserts a new node before C
• del deletes a given node
• Separation of traversal and modification of
• document structure (T/M)
• content (S/X)
• direct jumps (IDR/IDX)
• no intention locks!

• 0. Doc2PL only locks roots
• 1. Node2PL acquires locks for parent nodes

lock modes
content structure
S X T M
S - -
X - - -
T -
M - - - -
entire child axis of P affected
Structural navigation to locate an object often
implies ako document scan repeatable read
requires T locks on all nodes
5
Doc2PL and its Followers (2)

• 2. NO2PL
• acquires locks for all nodes whose (conceptual)
  pointers are traversed or modified
• example at C1 insB (C0)

• 3. OO2PL
• locks (conceptual) pointers for every node
• A/Z first/last child
• R/L next/previous sibling
• example del C2

only context node and selected child nodes
affected
Increasing degree of concurrency Doc2PL -gt
Node2PL -gt NO2PL -gt OO2PL
6
Making Full-Fledged Protocols for the -2PL Group
Idea of T/M lock modes - requires
non-interrupted path traversal - prohibits
indexed document access how to protect the
ancestor path in case of direct jumps?
T
root
root
M
IDS
IDX
IDX
IDS
Whats about IDREF(S) links?
locks for direct jumps (IDS/IDX) needed!
A single lock on the jump target is only
sufficient for read ops!
(Very expensive) solution for the -2PL
groupnode deletion requires IDX locks on all
descendents having ID attr.
7
What Else Do Full-Fledged XML Protocols Need?

• Support of direct access via indexes
• jumps to element nodes not owning an ID attribute
• cheap mechanism to identify the ancestor node
  IDs!
• Lock conversion
• operations of a transaction necessarily share
  some part of the ancestor path
• weakest possible locks after conversion
• Appropriate intention locks and subtree locks
  needed
• lock depth parameter desirable
• Use ideas of MGL locking
• subtree locks intention locks
• 4. IRX
• 5. IRX
• specialized conversion ()
• depending on locking situation

compatibility matrix
conversion matrix
- I R X
I I I X X
R R X R X
X X X X X
- I R X
I - -
R - -
X - - -
conversion matrix
- I R X
I I I R/X X
R R R/X R X
X X X X X
8
Applying Multi-Granularity Locking to XML

• 6. IRIX conversion
• read C1 C3
• delete C2

• 7. IRIX specialized conversion
• read C1 C3
• delete C2

- IR IX R X
IR IR IR IX R X
IX IX IX IX X X
R R R X R X
X X X X X X
- IR IX R X
IR IR IR IX R X
IX IX IX IX IXR X
R R R IXR R X
X X X X X X
9
MGL Group (Cont.)

• 8. URIX
• compatibility matrix
• conversion matrix

• read for update C1 C3
• delete C2

- IR IX R RIX U X
IR - -
IX - - - -
R - - - -
RIX - - - - -
U - - - -
X - - - - - -
- IR IX R RIX U X
IR IR IR IX R RIX U X
IX IX IX IX RIX RIX X X
R R R RIX R RIX R X
RIX RIX RIX RIX RIX RIX X X
U U U X U X U X
X X X X X X X X
10
Tailored Node Locks for XML taDOM2

• 9. taDOM2
• Node locks and compatibility matrix
• refined URIX protocol with extensions to lock a
  complete level in a subtree
• well known IR/IX and R/X (here SR/SX)
• edge locks not discussed (3 modes)

Read locks
Compatibility matrix
lock effect
IR intention read lock on a node
NR (node read) locks only a context node
LR (level read) read lock on a context node and all direct-child nodes
SR (subtree read) read lock on an entire subtree
- IR NR LR SR IX CX U X
IR - -
NR - -
LR - - -
SR - - - -
IX - - -
CX - - - -
SU - - - -
SX - - - - - - - -
Write locks
lock effect
IX (intent. excl.) intention of a write lock on a non-direct child node
X (exclusive) write lock on an entire subtree
CX (child excl.) indicates existence of a write lock on a direct child node
SU (update option) read lock for intended update operations on an entire subtree
11
Node Locks (1)

• Node read lock (NR)
• requires IR locks on the ancestor path
• Level read lock (LR)
• requested for reading the context node and all
  nodes located at the level below (all
  direct-child nodes)
• Child exclusive lock (CX)
• indicates an X lock on a child
• defined, in addition to IX, to detect conflicts
  with LR

Transaction T1 is reading ltpricegt
IR
IR
NR
12
Node Locks (2)

• Locking subtrees exclusively intention exclusive
  lock (IX), child exclusive lock (CX), and
  exclusive lock (X)
• requested for updating the context node's content
  or deleting the context node and its entire
  subtree
• requires a CX lock on the parent and IX locks on
  the ancestors

Transaction T1 is deleting the ltfirstgt node and
its content
13
Tunable Lock Depth

• Goal
• reduce the number of locks held by usingcoarser
  lock granularity
• may decrease concurrency
• when nodes deeper than lock depth are
  accessedlock modes SR and X are used at the
  lock depth level

Transaction T1 is reading the author's last name
Transaction T2 is updating the author's first name
Transaction T1 would have to acquire an SR lock
on author
Transaction T2 would have to acquire an X lock on
author
and would therefore have to wait on author
14
Conversion of Node Locks

• Conversion for weakest possible locking paths
• LR ? CX requires explicit NR locks on all
  children
• node labeling scheme cannot deliver IDs of
  descendent nodes

conversion matrix
- IR NR LR SR IX CX SU SX
IR IR IR NR LR SR IX CX SU SX
NR NR NR NR LR SR IX CX SU SX
LR LR LR LR LR SR IXNR CXNR SU SX
SR SR SR SR SR SR IXSR CXSR SR SX
IX IX IX IX IXNR IXSR IX CX SX SX
CX CX CX CX CXNR CXNR CX CX SX SX
SU SU SU SU SU SU SX SX SU SX
SX SX SX SX SX SX SX SX SX SX
X
Transaction T1 is deleting ltauthorgt and its
entire subtree
15
taDOM Group Lock Protocol Optimization

• 10. taDOM2 LRIX, SRIX, LRCX, SRCX
• new lock modes enable conversion without
  accessing the document
• e.g., LRCX (level read child exclusive) combines
  both modes and avoids application of conversion
  rule CXNR
• Optimization steps
• 11. taDOM3 modification of a single context node
• 12. taDOM3 new lock modes to avoid document
  access

Example lock conversion in taDOM3
16
XTC Architectural Overview
Interface Services
Http Agent
Ftp Agent
DOM RMI
SAX RMI
API RMI
XML Processing Services
XML Manager
XSLT Processor
XQuery Processor
Node ProcessingServices
Path Processing
Transaction Services
Node Manager
Lock Manager
Access Services
Record Mgr
Index Mgr
Catalog Mgr
Transaction Manager
Propagation Control
Deadlock Detector
Buffer Manager
File Services
XTCserver
Temp File Mgr
I/O Manager
OS File System
determination of ancestor node IDs are of
outmost importance for any locking protocol
17
taDOM Storage Model View of Lock Mgr

• XML documentlt?xml version"1.0"?gtltbibgt ltbook
  year"2004" id"book1"gt lttitlegtThe
  Titlelt/titlegt ltauthorgt
  ltlastgtLastnamelt/lastgt ltfirstgtFirstnamelt/firs
  tgt lt/authorgt ltpricegt49.99lt/pricegt
  lt/bookgtlt/bibgt

18
Identifying Nodes Node Numbering Schemes
sequential

• very slow, although supported by on-demand
  indexes
• determination of parent ID and ancestor IDs,
  however, is very frequent

19
Meta-Synchronization

• Meta-synchronization
• allows identical runtime environment for lock
  contests
• lock mgr provides methods supportsSharedLevelLock
  ing, supportsSharedTreeLocking,
  supportsExclusiveTreeLocking
• Meta-lock requests from node manager to lock
  manager
• request shared node lock
• request shared level lock
• request tree lock (shared, update, exclusive)
• . . .
• Meta-lock requests are mapped to the actual lock
  algorithm
• lock manager implements a certain interface
• exchange of the lock manager interface
  implementation exchanges the system's complete
  XML locking mechanism

Advantages of SPLIDs used in all 12 protocols!
20
TaMix Benchmark Framework

• So far, no update benchmark for XML docs
  available
• TaMix infrastructure for distributed OLTP
  benchmarks
• a list of TX types is assigned to each client
• each client runs n TX in parallel and keeps the
  workload level
• Automated measurement
• per measurement point 3 runs
• configurable runtime interval
• for 12 lock protocols
• in 6 lock depths
• 20 hours per measurement

21
Performance Measurement

• Data base (DataGuide)
• Size
• 8 MB
• 580,000 taDOM nodes

22
Performance Measurement (2)

• Transaction types for Banking benchmark
• bank transfer (5 TX/client)
• jump to a randomly selected account element
• navigation through the document, update
  operations for Balance and Posting
• standing order (5 TX/client)
• random account, navigation to Standing Orders,
  read of all orders
• evaluation of the Child axis, small fraction of
  update operations
• customer master
• renaming of a Customer element (1 TX/client)
• in parallel, reconstruction of randomly selected
  Customer fragments (5 TX/client)
• account statement (5 TX/client)
• reconstruction of randomly selected Account
  fragments
• small amount of update operations (insertion an
  entry in Protocols)
• removal of a customer from the data base (2
  TX/client)
• deletion of fragments
• Transaction mix
• processes all transaction types in parallel
• constant system load of 66 transactions

23
Performance Measurement (3)

• Number of committed transactions in Banking
  benchmark

lock depth
24
Performance Measurement (4)

• Number of aborted transactions in Banking
  benchmark

lock depth
25
Detailed Performance Measurement (5)

• Successful bank transfers
• node-based navigation, update operations

lock depth
26
Detailed Performance Measurement (6)

• Successfully modified standing orders
• evaluation of child axis, few update operations

lock depth
27
Detailed Performance Measurement (7)

• Customer Master successfully modified Customer
  elements reconstructed Customer fragments
• renaming of an inner element node

lock depth
28
Detailed Performance Measurement (8)

• Successfully processed account statements
• reconstruction of fragments, few update operations

lock depth
29
Detailed Performance Measurement (9)

• Successfully removed customer records
• deletion of fragments

30
Conclusions and Outlook

• XTC is used as a test vehicle for empirical DB
  research
• effectiveness of XML concurrency control
• fine-granular locking on nodes and edges
• meta-synchronization allows comparison of
  different compatibilities
• taDOM protocols
• multiplicity of lock modes
• intention locks are important
• indexed document access is frequent
• ancestor path locking without accessing the
  storage engine desirable
• performance evaluation revealed
• use of tailored lock modes pays off
• indexed document access is frequent
• effect of isolation levels on transaction
  throughput
• influence of node numbering schemes (insertions
  at arbitrary positions)
• Outlook
• phantom prevention
• mapping different XML language models via access
  models to our XML storage model, e. g., to
  analyze the locking behavior of XQuery processing

31
Contest of XML Lock Protocols
Thank you. Any questions?