transaction management for xml
DESCRIPTION
Transaction Management for XML. Taro L. Saito Department of Information Science University of Tokyo E-mail : [email protected]. Introduction. Research Trends on XML Query languages XML-QL, XQuery, XDuce, etc… Update extension of XQuery (2001) Most of them implicitly assume - PowerPoint PPT PresentationTRANSCRIPT
-
Transaction Management for XMLTaro L. SaitoDepartment of Information ScienceUniversity of TokyoE-mail : [email protected]
-
IntroductionResearch Trends on XMLQuery languages XML-QL, XQuery, XDuce, etcUpdate extension of XQuery (2001)
Most of them implicitly assume single user environments.
-
XML as DatabaseMultiple Users 1~1000, or more? Querying and updating occur simultaneouslyTransaction ManagementAtomicity of query and update operationsAll-or-nothing executionConsistency and Concurrency ControlLocking system
-
AchievementsXerialTransactional Database for XMLConcurrent TransactionsSerializable scheduleRecoverabilityHandling transaction aborts and system failures Updating XMLNode insertion, deletion, modification, etc.Transaction LanguageQuery and update notations
-
Xerial OverviewXMLStorageQueryCompilerTransaction Requests Transaction Scheduler Serializable ScheduleDB AccessSystemOutputsactionsXMLsourcexml2dbLock RequestsLockTableRead & WriteLogMulti-Thread
-
Data Model
Jeffrey New York Notebook 2002/02/11 50 Blank Label 2002/02/10 100 delivered
-
Querying XMLXQueryW3C standardQuery Language for XMLUse of Path expressionsBind elements to a variableorderorderFOR $x IN /customer/orderFOR $x IN /customer/orderWHERE $x/date = 2002/02/13
-
Locks for Tree-StructureSubtree Level LockingQuery to entire subtree is frequent in XMLReduce the # of locksPerformance FactorThe number of locksLoad of lock manager Granularity of locksConcurrency
-
Lock Range ReductionUse Attribute DataRead OnlyAvailable without locks/customer/order[@oid=3]
orderoid
-
Transaction Management
-
OperationsQueryXQuery Syntax FOR, WHERE, RETURNUpdateInsertionDeletionModification
-
Transaction LanguageSET $x = /customerTRANSACTION $x { FOR$y IN $x/name,$z IN $x/city WHERE $y = Jeffrey RETURN $z} SET $x = /customer[@id=C-032]TRANSACTION $x { FOR $o IN $x/order, $p IN $o/price WHERE $o/item = book, $p > 10000 INSERT $o { tax has been imposed } WRITE $p $p * 1.10}Basic SyntaxUpdate Transaction
-
LocksCompatibility MatrixOrdinal LocksS Shared Lock (read)X Exclusive Lock (write)WarningsIS Intention to ShareIX Intention to Exclusive
ISIXSXISYesYesYesNoIXYesYesNoNoSYesNoYesNoXNoNoNoNo
-
Warning ProtocolJim Gray et al, 1975.Original Rules All transactions must enter from the rootTo place a lock or warning on any element, we must hold a warning on its parentNever remove a lock or warning unless we hold no locks or warnings on its children
EDFBACISS
-
Warning Protocol for XMLExtensionWhen we insert or delete nodes, we must obtain X lock on the parent of the destination Until we place a warning on a node, we cannot trace its pointers to the childrenA transaction never release locks or warnings until it finishes2 phase locking
EDBACXIX
-
SerializabilitySerial ScheduleIf the effect on the database is equivalent to that of some serial schedule, the schedule is serializable2-phase locking is serializable (theory)The warning protocol becomes serializable
-
Recoverability2 Phase LockingNo dirty readNo cascading rollbackRecovery From transaction aborts and system failuresBy using log records
-
Experimental Results
-
HardwarePentium III 1GHz, Dual ProcessorMain Memory 2GBHard Disk * 210000 RPM, Ultra160 SCSINTFS format (Windows 2000)For database and log
-
Data SourceXML Representation of TPC-CRandom Data11.5 MB3433271 tags17555 attributes293160 data
TPC-CBenchmark for online transaction processing on Relational Databases
W=5D=10C=50Order=5
-
Transaction SetsRandom 10,000 Transaction SetsS1Low ConcurrencyS2Insertion Intensive (more general)
Transactions
Lock Node
Mode
Insert
Modify
Delete
S1 (%)
S2 (%)
Search District
Warehouse
S
0
0
0
40
5
Insert Customer
District
X
30
1
0
20
10
Delete Customer
District
X
0
1
30 ~
10
2
Insert Order
Customer
X
22
1
0
15
40
Write Payment
Customer
X
0
2
0
10
25
Delete Order
Customer
X
0
1
22 ~
3
3
Order Status
Order
S
0
0
0
2
15
-
MethodologyCompare 2 Methods(a) The warning protocol (parallel)(b) Obtain an X lock on the root (serial)Lock the whole databaseMeasure Transaction ThroughputAverage Response Time
-
ResultsS1S2(a) parallel(b) serial(a) parallel(b) serialnumber of transactionnumber of transactiontime (sec.)time (sec.)
Lock Time
Update Time
Response Time
Elapsed Time
(10,000 Transactions)
Transactions
Per Second
S1 (a)
0.41702
0.06018
0.47956
96.328
103.812
(b)
0.75634
0.01039
0.76891
154.625
64.672
S2 (a)
0.30730
0.10657
0.41726
84.05
118.977
(b)
0.88859
0.00787
1.28200
180.33
55.453
-
Future WorkMore Complex OperationsJoin operation between subtreesPossibility of deadlocksDegrees of ConsistencyLower the consistency for increasing the performanceOther Consistency ManagementsTime stampVersioningMulti-version 2 phase lockingetc.
-
XMLXML 2001XMLXML1000all-or-nothingconcurrency consistencyXerialXMLXerialserializabilityTransaction Language
Xerial XMLxml2db
XerialXMLattribute
W3CXQueryWHEREXMLsubtreeXerialsubtreeorder100ordercustomerconcurrencytradeoff
concurrencyXerialattributeread-onlyattributeXerialXQuerySyntaxSETsubtreeTRANSACTION clauseQueryXMLXerialwarningSISXIXwarningsubtreewarning protocolJim Gray1975warning SsubtreeXerialwarning protocolXMLinsertiondeletionX22-phase
serializabilityserial schedule2-phaseserializablewarning protocol2-phase lockingdirty readcascading rollback
XMLTPC-CXML
S1, S22S1S2insertionS1,S2warning protocolXresponse time10000S1S2warning protocol1118
subtreejoindead lockconsistencyconsistency management