Advanced Database Management Systems

Assignment 01
D.M.J.A.B.Dissanayake E101040005 3/6/2012

ITE 3802 - Advanced Database Management Systems E10104005

1. Briefly explain two reasons for an incomplete transaction by giving suitable examples(20 Marks) The database transaction means, one or more operations collected as a single logical unit of database work. Database transactions are usually activated by user requests in SQL or other Data Manipulation Languages. Most real-world database transactions are based on two or more requests. Transactions access the database via reading and/or writing operations: They may INSERT, UPDATE, DELETE, or SELECT data; They may modify the values of attributes in tables; They may also change the physical structure of the database itself. The scope of a database transaction is defined by the user when he or she initiates it. Once started, a transaction must be ended either with COMMIT or ROLLBACK. A successfully completed transaction ends with COMMIT to permanently record the transaction results in the database. A failed and then aborted transaction ends with ROLLBACK to undo the transaction effects on the database. Committed transactions change the database from one consistent state to another. When a transaction is not completed without issuing a COMMIT or ROLLBACK statement is called incomplete transaction. Transaction may be incomplete for three reasons. Aborted System cash Terminate itself because of read error or disk failure. Aborted When a transaction fails, it is aborted. When a transaction is partially committed and then fails, it is aborted. When a transaction is committed, it is successful. The states of a transaction are shown in the figure below.

ITE 3802 - Advanced Database Management Systems E10104005

Example 1. Transaction Manager 1 (TM1) is the root transaction manager in the transaction tree and it coordinates the Two-Phase Commit protocol for all participants. Interactions explained in this example are illustrated in the following figure.

Figure 02: Example 1: Transaction is aborted during Two-Phase Commit protocol The messages exchanged in this example are contained within the Two-Phase Commit Notifications action between the system and participating roles. The message flow shown in this example is as follows: 1. Transaction Manager (TM1) sends a PrepareRequest message to Resource Manager 1 (RM1). 2. TM1 sends a PrepareRequest message to Transaction Manager 2 (TM2). 3. TM2 sends a PrepareRequest message to Resource Manager 2 (RM2). 4. RM1 sends a PrepareRequestDone message to TM1 indicating that the prepare request was finished successfully (OK), completing step 1. 5. RM2 sends a PrepareRequestDone message to TM2 indicating that the prepare request was finished unsuccessfully (Abort), completing step 3. 6. TM2 sends a PrepareRequestDone message to TM1 indicating that the prepare request was finished unsuccessfully (Abort), completing step 2.

ITE 3802 - Advanced Database Management Systems E10104005 7. TM1 determines the outcome as Abort and sends a Failure message to APP indicating that the transaction is aborted, completing step 22 in Example 1. 8. TM1 sends an AbortRequest message to RM1. 9. RM1 sends an AbortRequestDone to TM1, completing step 8. System cash The system crash, or fatal error, causes a process to terminate transactions abnormally. There are various possible reasons for a crash. For example, a crash can occur due to a bug in the HotSpot VM, in a system library, in a Java SE library or API, in application native code, or even in the operating system. External factors, such as resource exhaustion in the operating system can also cause a crash. Power failures or other hardware or software failures leads to system to crash too. Example 2: Crash in Native Code If the fatal error log indicates that the crash was in a native library, there might be a bug in native code or JNI library code. The crash could of course be caused by something else, but analysis of the library and any core file or crash dump is a good starting place. For example, consider the following extract from the header of a fatal error log: # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x417789d7, pid=21139, tid=1024 # # Java VM: Java HotSpot(TM) Server VM (6-beta2-b63 mixed mode) # Problematic frame: # C [libApplication.so+0x9d7] In this case a SIGSEGV occurred with a thread executing in the library libApplication.so. In some cases a bug in a native library manifests itself as a crash in Java VM code. Consider the following crash where a JavaThread fails while in the _thread_in_vm state (meaning that it is executing in Java VM code) : # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x08083d77, pid=3700, tid=2896 # # Java VM: Java HotSpot(TM) Client VM (1.5-internal mixed mode) # Problematic frame: # V [jvm.dll+0x83d77] --------------- T H R E A D --------------Current thread (0x00036960): JavaThread "main" [_thread_in_vm, id=2896] : Stack: [0x00040000,0x00080000), sp=0x0007f9f8, free space=254k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

ITE 3802 - Advanced Database Management Systems E10104005 V [jvm.dll+0x83d77] C [App.dll+0x1047] <========= C/native frame j Test.foo()V+0 j Test.main([Ljava/lang/String;)V+0 v ~StubRoutines::call_stub V [jvm.dll+0x80f13] V [jvm.dll+0xd3842] V [jvm.dll+0x80de4] V [jvm.dll+0x87cd2] C [java.exe+0x14c0] C [java.exe+0x64cd] C [kernel32.dll+0x214c7] :

2. Explain two considerations in a serializable transaction.(20 Marks) The serializable transaction operates in an environment that makes it appear as if there are no other users modifying data in the database. The database will be "frozen" at the point in time your query began. Your transaction sees the database consistently, at a single point in time. Changes made by other transactions are not visible to it, regardless of how long it has. The application requires absolute accuracy for long-running multistatement transactions and must hold all requested data from other modifications until the transaction finishes. Additionally, the transactions are requesting sets of data and not just singleton rows. Each set must produce the same output at each request within the transaction, and other users cannot modify the data that has been read and cannot insert new rows into the set. This is best when the application is relying on consistent data, plans to modify it later within the same transaction, and requires absolute accuracy and data consistency up to the end of the transaction. Two method of Serialiability are available: Conflict Serialiability and view Serialiability

3. Illustrate the Lock-Based concurrency control technique by using suitable examples. (60 Marks) A lock is mechanism to control current access to a data item. Each transaction needs a certain lock to get access to data. After the transaction has been finished, the lock should be released. There are two kinds of locks: shared mode lock(S-lock) and exclusive-mode lock(X-lock). If Ti obtains an S-lock for item Q, it can read but cannot write Q. On the other hand, if Ti obtains an X-lock for item Q, it can both read and write Q. So, that is, if a transaction

ITE 3802 - Advanced Database Management Systems E10104005 wants only read data Q, it should apply an S-lock for item Q transaction wants to read and write data Q, it should apply for an X-lock for Q. Type of lock Read Write S Yes No X Yes Yes

For another thing, if there is a lock on the data, it will to a problem called compatibility. A compatibility function can describe this. If the transaction can get the data Q, the value of compatibility function is TRUE, otherwise it is FALSE. The table shows the relationship between compatibility and types of lock. Type of lock S X S TRUE FALSE X FALSE FALSE

Lock manager: Lock manager is in charge of granting a lock. There are two principles to grant a lock: Principle 1: There is no other transaction holding a lock on Q in a mode that convicts with M. Principle 2: There is no other transaction that is waiting for a lock on Q and that made its lock request before T. Two phase of Locking Protocol: Growing phase: transactions can only obtain locks. Shrinking phase: transactions can only release locks. Two kinds of protocols: Strict Two-phase Locking Protocol: Exclusive-mode lock will be held until the end of the transaction. Rigorous Two-phase Locking Protocol: All the locks shall be held until the end of the transaction. Example: If T wants to read (modify) an object, first obtains a shared (exclusive) lock If T releases any lock, it can acquire no new locks! Two accounts, A and B Two transactions, T1 and T2 T1: Transfer Rs.100 from A to B T2: Add 10% interest to A and B

ITE 3802 - Advanced Database Management Systems E10104005 T1 acquires S lock on A T1 acquires X lock on A T1 acquires S lock on B T1 acquires X lock on B T1 releases all locks T2 acquires S lock on A

Precedence (or serializability) graph for schedule S A node for each committed transaction in S An arc from Ti to Tj if some action in Ti precedes and conflicts with some action in Tj

T1

T2

T3

2PL guarantees an acyclic precedence graph Guarantees a serializable schedule Intuitively, equivalent serial schedule given by order in which transactions enter shrinking phase.

Thank You, D.M.J.A.B.Dissanayake E101040005

ITE 3802 - Advanced Database Management Systems E10104005