PAVANI REDDY KATHURI

TRANSACTION COMMUNICATION

OUTLINE

0 PART I: INTRODUCTION

0 PART II: CURRENT RESEARCH

0 PART III: FUTURE POTENTIAL

0 REFERENCES

WHAT IS TRANSACTION?

0Fundamental unit of interconnection b/w client and server processes in database system.

In Transactions we have, Database Transaction Communication Transaction

ACID PROPERTIES

0 Atomicity0 Consistency0 Isolation0 Durability

ATOMICITY

0 Either all the operations in a transaction are performed in its entirety or not performed at all.

CONSISTENCY0 consistent state is maintained before a transaction

starts and after it concludes.

0ISOLATION A transaction should appear as it is being executed in isolation form other transactions.

0DURABILITY Transactions results are locked/ permanent after being committed.

DISTRIBUTED TRANSACTION

0 One coordinator (usually the initiator of the transaction) and several participating processes (remote process)

0 At commitAtomicity: either all nodes commit or none doIsolation: effects of the transaction not made visible

until all nodes have made an irrevocable decision to commit or abort

ACTIVITY LOG

Each participant keeps track of updated data objects by maintaining a private work space. Updates contain old and new value. Each site has an activity log which is kept on the disk.0- On abort: undo of uncommitted transactions (rollback)0- After crash: redo of committed transactions (roll forward) Needed for durability of committed transactions

SHADOW PAGING

Here, transaction logs are not required. Two directories created during the life of transaction

- current directory - shadow directory

When transaction starts, both directories are same. Shadow directory never changed during the transaction. Current directory updated when write operation is

performed. When transaction commits, shadow directory is

discarded and current directory is copied to the storage

TWO PHASE COMMIT PROTOCOL

COORDINATOR•precommit the transaction•Send request to all participants

request

PARTICIPANT•received request message•If (ready)•precommit and send YES

•Else ABORT send NO

reply

COORDINATOR• collect all replies

COORDINATOR• If (all votes are

unanimous)• Commit & send COMMIT

• Else ABORT & send ABORT

decision

PARTICIPANT•receive decision•If (COMMIT) commit•If (ABORT) abort

•send response

result

COORDINATOR•received response

1st Phase

2nd Phase

2PCCOORDINATOR1. Prepare to commit the transaction by writing every

update in activity log. within the time-out period, multicast a commit message. Otherwise, multicast an abort message.

2. Write a precommit message in the activity log. Send a voting message to all participants asking whether they are ready to commit.

3. If all participants vote yes

PARTICIPANT

1. Prepare to commit the transaction by writing every update in activity log.

2. Write a precommit message in the activity log. Wait for request to vote from coordinator.

3. When receiving a vote request, test whether the transaction can be committed and if yes, writes a precommit to its activity log and sends a YES reply, otherwise send a NO reply.

4. Wait for commit message from the coordinator. If received, commit the transaction. If abort message is received, abort the transaction.

FAILURE AND RECOVERY ACTIONS

Failures before precommit(s)

• Abort transaction• Equiv to send NO

Failures after precommits but prior to commit

• Abort transaction• Re-multicast

request message

Failures after a commit

• Resend commit message

PARTICIPANT1. Prepare to commit the transaction by writing every

update in activity log.

2. Write a precommit message in the activity log. Wait for request to vote from coordinator.

3. When receiving a vote request, test whether the transaction can be committed and if yes, writes a precommit to its activity log and sends a YES reply, otherwise send a NO reply.

4. Wait for commit message from the coordinator. If received, commit the transaction. If abort message is received, abort the transaction.

RELATED LINK

0 http://en.wikipedia.org/wiki/Two-phase_commit_protocol

NESTED TRANSACTION

Nested transaction = tree of transactions0 Commit of a subtransaction takes place only if parent

transaction commits0 Rollback of a transaction forces rollback of all its

subtransactions

RULES FOR NESTED TRANSACTIONS

Commit rule0 Commit of a transaction makes it result accessible only

to its parent

Rollback rule0 If a transaction is rolled back, all its subtransactions are

also rolled back (whatever their status)

RULES FOR NESTED TRANSACTION (CONT’D)

Visibility rule0 All changes by a subtransaction are visible to

parent upon local commit.

Locking rule0 Externally, top-level transaction holds all locks0 Internally, multiple transactions may hold exclusive

locks

CURRENT RESEARCH

X/Open XA [IBM, Wiki, 2009]:0 What is it?0 Standard specification for distributed transaction

processing (DTP).0 Provides interface between the global transaction

manager and the local resource manager.

X/OPEN XA

PROBLEM: we can access multiple resources, but with multiple transactions there’s a lot of overhead [IBM, 2009].

0 XA allows multiple resources (databases, app servers, etc.) to be accessed within the same transaction.o Preserves ACID properties across applications.o Uses 2PC implementation to ensure that all resources

either commit, or rollback, any particular transaction simultaneously.

20

© 2009 Georgia State University

RELATED LINKS

[1] “X/Open XA”, http://en.wikipedia.org/wiki/X/Open_XA, 8-9-2009.

[2] “X/Open XA Standard”, http://www.opengroup.org/onlinepubs/009680699/toc.pdf, 1991

FUTURE WORK

PROPOSAL

SALES PITCH?

Does any product sell itself? No! There’s heavy marketing, promoting, and partnering involved.

Open XA caters to Data Warehousing with tight hardware coupling [IBM, Wiki, 2009].

While initial benefits start at the basics:o Fewer transactionso Lower costs

Hardware costs have decreased, but depending on the specifics of a system, server & hardware costs can run high!!!

PROS0 Provides abstraction of resources.0 User can forgo hardware specifics and it’s cheaper.0 Multiple virtualization modes can be used based on the nature of

the transaction.o Para, Partial, Full

CONS

Can NOT remove all traces of hardware either for a DW. Security and authority concerns. Performance differences for large tasks. There’s no central Authority for Open Source lead

efforts. IT support trickles in late. Implementation and security concerns.

REFERENCES

[1] Distributed Operating Systems & Algorithms, by Randy Chow and Theodore Johnson, 1997[2] “Securing Applications using Operating System Transactions”, Erez

Zadok, http://cip.cs.stonybrook.edu/ workshop/slides/3-zadok.pdf, 7-14-2006.

[3] “Operating System Transactions”, Donald E. Porter, Owen S. Hofmann, Christopher J. Rossbach, Alexander Benn, and Emmett Witchel, 22nd ACM Symposium on Operating Systems Principles, October 2009

[4] Mohammad Alrifai etc., Transactions Concurrency Control in Web Service Environment,2000

THANK YOU