Name: TAN LIEU YONG

Matric number: WEK100071 WXES2114 TRANSACTION MANAGEMENT TUTORIAL SCHEMA

1. What is a transaction log, and what is its function? A transaction log is a special DBMS table that contains a description of all the database transactions executed by the DBMS. It plays a crucial role in maintaining database concurrency control and integrity. The information stored in the log is used by the DBMS to recover the database after a transaction is aborted or after a system failure. The transaction log is usually stored in a different hard disk or in a different media (tape) to prevent the failure caused by a media error. 2. ABC Markets sells products to customers. The relational diagram shown in Figure P10.6 represents the main entities for ABCs database. Note the following important characteristics:
A customer may make many purchases, each one represented by an invoice. The CUS_BALANCE is updated with each credit purchase or payment and represents the amount the customer owes. The CUS_BALANCE is increased (+) with every credit purchase and decreased (-) with every customer payment. The date of last purchase is updated with each new purchase made by the customer. The date of last payment is updated with each new payment made by the customer. An invoice represents a product purchase by a customer. An INVOICE can have many invoice LINEs, one for each product purchased. The INV_TOTAL represents the total cost of invoice including taxes. The INV_TERMS can be 30, 60, or 90 (representing the number of days of credit) or CASH, CHECK, or CC. The invoice status can be OPEN, PAID, or CANCEL. A products quantity on hand (P_QTYOH) is updated (decreased) with each product sale. A customer may make many payments. The payment type (PMT_TYPE) can be one of the following: CASH for cash payments. CHECK for check payments CC for credit card payments

 The payment details (PMT_DETAILS) are used to record data about check or credit card payments: The bank, account number, and check number for check payments The issuer, credit card number, and expiration date for credit card payments

Using this database, write the SQL code to represent each one of the following transactions. Use BEGIN TRANSACTION and COMMIT to group the SQL statements in logical transactions. Note: Not all entities and attributes are represented in this example. Use only the attributes indicated. a. On May 11, 2010, customer 10010 makes a credit purchase (30 days) of one unit of product 11QER/31 with a unit price of $110.00; the tax rate is 8 percent. The invoice number is 10983, and this invoice has only one product line. BEGIN TRANSACTION INSERT INTO INVOICE VALUES(10983, 10010, 11-May-2010, 118.80, 30, OPEN); INSERT INTO LINE VALUES(10983, 1, 11QER/31, 1, 110.00); UPDATE PRODUCT SET P_QTYOH = P_QTYOH 1 WHERE P_CODE = 11QER/31; UPDATE CUSTOMER SET CUS_DATELSTPUR = 11-May-2010, CUS_BALANCE = CUS_BALANCE + 118.80 WHERE CUS_CODE = 10010; COMMIT; b. On June 3, 2010, customer 10010 makes a payment of $100 in cash. The payment ID is 3428.

BEGIN TRANSACTION INSERT INTO PAYMENTS VALUES(3428, 03-Jun-2010, 10010, 100.00, CASH, None); UPDATE CUSTOMER SET CUS_DATELSPMT = 03-Jun-2010, CUS_BALANCE = CUS_BALANCE 100.00 WHERE CUS_CODE = 10010; COMMIT;

3. Create a simple transaction log (using the format shown in class) to represent the actions of the two previous transactions.
Note: Because we have not shown the table contents, the "before" values in the transaction can be assumed. The "after" value must be computed using the assumed "before" value, plus or minus the transaction value. Also, in order to save some space, we have combined the "after" values for the INSERT statements into a single cell. Actually, each value could be entered in individual rows.
TRL ID 987 1023 TRX NUM 101 101 PREV PTR Null 987 NEXT PTR 1023 1026 OPERATION START INSERT TABLE * Start Trx. INVOICE ROW ID 10983 ATTRIBUTE BEFORE VALUE AFTER VALUE 10983, 10010, 11-May2010, 118.80, 30, OPEN 10983, 1, 11QER/31, 1, 110.00 46 464.47 11-May2010

1026 1029 1031 1032 1034 1089 1091

101 101 101 101 101 102 102

1023 1026 1029 1031 1032 Null 1089

1029 1031 1032 1034 Null 1091 1095

INSERT UPDATE UPDATE UPDATE COMMIT START INSERT

LINE PRODUCT CUSTOMER CUSTOMER * End Trx. * * Start Trx. PAYMENT

10983, 1 11QER/31 10010 10010 P_QTYOH CUS_BALANCE CUS_DATELSTPUR 47 345.67 5-May2006

3428

1095 1096 1097

102 102 102

1091 1095 1096

1096 1097 Null

UPDATE UPDATE COMMIT

CUSTOMER CUSTOMER * End Trx.

10010 10010

CUS_BALANCE CUS_DATELSTPMT

464.47 2-May2006

3428, 3Jun-2010, 10010, 100.00, CASH, None 364.47 3-Jun-2010

4. What is a lock, and how, in general, does it work? A lock is a mechanism used in concurrency control to guarantee the exclusive use of a data element to the transaction that owns the lock. For example, if the data element X is currently locked by transaction T1, transaction T2 will not have access to the data element X until T1 releases its lock.

In general, a data item can be in only two states, which are locked (being used by some transaction) or unlocked (not in use by any transaction). To access a data element X, a transaction T1 first must request a lock to the DBMS. If the data element is not in use, the DBMS will lock X to be used by T1 exclusively. No other transaction will have access to X while T1 is executed.
5. What are the different levels of lock granularity? Lock granularity describes the different lock levels supported by a DBMS. The lock levels are:

(I)Database-level The DBMS locks the entire database. If transaction T1 locks the database, transaction T2 cannot access any database tables until T1 releases the lock. Database-level locks work well in a batch processing environment when the bulk of the transactions are executed off line and a batch process is used to update the master database at off peak times such as midnight, weekends, etc. (II)Table-level The DBMS locks an entire table within a database. This lock level prevents access to any row by a transaction T2 while transaction T1 is using the table. However, two transactions can access the database as long as they access different tables. Table-level locks are only appropriate when table sharing is not an issue. For example, if researchers pursue unrelated research projects within a research database, the DBMS will be able to allow such users to access their data without affecting the work of other users. (III)Page-level The DBMS will lock an entire disk-page. A disk page or page is the equivalent of a disk block, which may be described as a (referenced) section of a disk. A page has a fixed size, such as 4K, 8K, 16K, etc. A table may span several pages, and a page may contain several rows of one or more tables. Page-level locks are (currently) the most frequently used of the multi user DBMS locking devices. Page-level locks are particularly appropriate in a multi-user DBMS system in which data sharing is a crucial component. For example, page-level locks are common in accounting systems, sales systems, and payroll systems. In fact, just about any business DBMS application that runs in a multi-user environment benefits from page-level locking. (IV)Row-level The row level lock is much less restrictive than the locks we have just discussed. Row level locks permit the DBMS to allow concurrent transactions to access different rows of the same table, even if these rows are located on

the same page. Although the row level locking approach improves the availability of data, its management requires high overhead cost because a lock exists for each row in each table of the database. Row-level locking is yet to be implemented in most of the currently available DBMS systems. Consequently, row level locks are mostly a curiosity at this point. Nevertheless, its very high degree of shareability makes it a potential option for multi user database applications like the ones that currently use page level locking. (V)Field-level The field-level locking approach allows concurrent transactions to access the same row as long as they use different attributes within that row. Although field level locking clearly yields the most flexible multi user data access, it requires too much computer overhead to be practical at this point.