Distributed Databases: what is next?

Distributed Databases: what is next? Massive distribution / replication Nested transactions Transactions and web services Summary and final remarks New Challenges DDB and transactions in the past - few nodes ( < 10?) - stable systems - stable net Future - Mobile systems check out part of the DB and update "salesperson" application scenario Multimaster replication 2 ~100 replicas Handheld devices completely independent - Sensor net data transactions?? - Web Service transactions Replication schemes not scalable hs / FUB dbsii-03-21ddbnext-2

Nested Transactions Flat transaction model up to now: begin r(x), w(x) commit Why not recursive? TA ( r(x), TA1(..) w(x) TA2(..)) subtransaction Generalize savepoints - Savepoints allow sequential transactions to be aborted partially, work between two savepoints is a subtransaction Allow transaction /subtransaction trees Each subtransaction may be aborted hs / FUB dbsii-03-21ddbnext-3 Nested Transactions Nested transactions used to be an academic exercise, become very important right now - Object orientation each method call is (may be) a subtransaction - Business transactions between autonomous systems (e.g. coordination of web services) withdraw deposit Bank 1 Bank 2 hs / FUB dbsii-03-21ddbnext-4

Business Objects: example t 2 Withdraw (x, 1000) Deposit (y, 1000) Append (h,...) Search (...) Fetch (x) ^ Modify (x) ^ Fetch (a) Fetch (d) Store (e) Modify (d) Modify (a) Search (...) Fetch (y) ^ Modify (y) ^ r (r) r (l) r (p) r (p) w (p) r (s) r (t) r (t) w (t) r (t) w (t) r (s)w (s) r (r) r (l) r (q) r (q) w (q) Nested Transaction rules (*) Each transaction or subtransaction is bracketed by Start and Commit or Abort. If a program is not executing a transaction, then Start creates a new top-level transaction If a program is executing inside a transaction, then Start creates a subtransaction. Commit and Abort by a top-level transaction have the usual semantics If a subtransaction aborts, then all of its operations and subtransactions are undone top-level is notified, not aborted Until it commits, a subtransaction s updated data items are only visible to its subtransactions After a subtransaction S commits, S s updates are visible to other subtransactions of S s parent. (*) Bernstein hs / FUB dbsii-03-21ddbnext-6

Nested Transactions Features Top-level transactions like flat transactions. - They re ACID and bracketed by Start, Commit, Abort. Subtransaction abort is a new feature Subtransactions of the same parent are isolated from one another Parent may decide to compensate a subtransaction if another subtransaction aborts (sometimes called Multilevel TAs) hs / FUB dbsii-03-21ddbnext-7 Web service coordination "Webservice increasingly tie together a large number of participants forming large distributed applications" How to coordinate the activities? Coordination types in the web service transaction specification: - Atomic transactions (AT) used to coordinate activities having a short duration - Business activities (BA) used to coordinate activities that are long in duration and desire to apply business logic - Web service can include both ATs and BAs hs / FUB dbsii-03-21ddbnext-8

Web service coordination Example: Web service activities as nested transactions Coordination framework of WS consists of: - activation service - registration service - coordination service hs / FUB dbsii-03-21ddbnext-9 Web service coordination Activation: begin a new activity, specify coordination protocols available hs / FUB dbsii-03-21ddbnext-10

Web service coordination Registration service Register and select protocol for the activity Includes specification of transaction protocols and properties available for a particular web service Coordination service Controls activity completion processing for registered WS using selected coordination protocol (until now: atomic transaction and business coordination) Context for created activity: - Identifier - expire (activity timeout) - coordination type - registration service hs / FUB dbsii-03-21ddbnext-11 Transactional Web service: scenario of atomic TAs hs / FUB dbsii-03-21ddbnext-12

Example: Atomic TA Step 1: Application creates transactional activity using WS coordination framework's activation service Step 2: Application registers (as responsible driving the completion protocol) Step 3: Application performs operation on a Web service Step 4: Register Resource with Reg. service for processing (only the first time, compare XA) Step 5-7: Ack, application completes acitivty Step 8-11: 2PC hs / FUB dbsii-03-21ddbnext-13 Example: Business activity hs / FUB dbsii-03-21ddbnext-14

Example: Business activity abort No 2 PC Application decides to abort (Business Activity Failure) Coordinator sends compensation record Compare nested transactions Protocols defined in XML syntax with SOAP envelope.. BUT hs / FUB dbsii-03-21ddbnext-15 Specification for Web Service TA TWO different specifications by mainplayers - Microsoft / IBM et al. http://www.ibm.com/developerworks/library/wstanspec/ - Sun, Oracle, Iona et al (see reader) Seems to be more elaborate, includes e.g. subprotocols like - status of work -Restart - Checkpoint - Details: seminar next semester hs / FUB dbsii-03-21ddbnext-16

Trends for Transactions Business TA in large scale distributed, unstable systems Example: Buying electronic goods n offerors, 1 client, bank delivery payment accept offer: contract hs / FUB dbsii-03-21ddbnext-17 Trends for Transactions Example (cont.): Nested Transaction (offer) ( (contract (payment) (delivery) ) Important: - delivery must be successful if payment successful (electronic good!) - payment must precede delivery. Why? - payment sub TA must guarantee correctness ( don t create or destroy money ) compensation possible for payment (refund) not for delivery. Not covered: Trustworthiness of participants hs / FUB dbsii-03-21ddbnext-18

Trends for Transactions Business transactions in large scale distributed systems: may be nested compensation important atomicity is the problem, not (so much) isolation all or nothing too simple Specific protocols for different steps of TA like payment, contracts, hs / FUB dbsii-03-21ddbnext-19 Summary Web based business applications: large number of participants forming large distributed applications" New transaction models needed oriented towards less stable environments Web Service TAs: 2 different specifications Hot topic also for mobile systems Similar tendency for large scale replication (e.g. IceCube, MSR Cambridge -> seminar next summer) hs / FUB dbsii-03-21ddbnext-20