Group-2.pdf

INFORMATION
TECHNOLOGY
GROUP-2

SET
TRANSACTION
SYNTAX
A TRANSACTION IS A UNIT OF WORK THAT IS PERFORMED AGAINST A DATABASE.
TRANSACTIONS ARE UNITS OR SEQUENCES OF WORK ACCOMPLISHED IN A LOGICAL ORDER,
WHETHER IN A MANUAL FASHION BY A USER OR AUTOMATICALLY BY SOME SORT OF A
DATABASE PROGRAM.
A TRANSACTION IS THE PROPAGATION OF ONE OR MORE CHANGES TO THE DATABASE. FOR
EXAMPLE, IF YOU ARE CREATING A RECORD OR UPDATING A RECORD OR DELETING A RECORD
FROM THE TABLE, THEN YOU ARE PERFORMING A TRANSACTION ON THAT TABLE. IT IS
IMPORTANT TO CONTROL THESE TRANSACTIONS TO ENSURE THE DATA INTEGRITY AND TO
HANDLE DATABASE ERRORS.
PRACTICALLY, YOU WILL CLUB MANY SQL QUERIES INTO A GROUP AND YOU WILL EXECUTE ALL OF
THEM TOGETHER AS A PART OF A TRANSACTION.
https://www.youtube.com/watch?v=PhUgUTutiGk

COMMIT − TO SAVE THE CHANGES.
ROLLBACK − TO ROLL BACK THE CHANGES.
SAVEPOINT − CREATES POINTS WITHIN THE
GROUPS OF TRANSACTIONS IN WHICH TO
ROLLBACK.
SET TRANSACTION − PLACES A NAME ON A
TRANSACTION.
Transaction Control

Properties of Transactions
Atomicity − ensures that all operations within the work unit are
completed successfully. Otherwise, the transaction is aborted
at the point of failure and all the previous operations are rolled
back to their former state.
Consistency − ensures that the database properly changes
states upon a successfully committed transaction.
Isolation − enables transactions to operate independently of and
transparent to each other.
Durability − ensures that the result or effect of a committed
transaction persists in case of a system failure.

Transactional Control Commands
Transactional control commands are only used with the DML
Commands such as - INSERT, UPDATE and DELETE only. They cannot
be used while creating tables or dropping them because these
operations are automatically committed in the database.
The COMMIT Command
The COMMIT command is the transactional command used to save changes invoked by a
transaction to the database. The COMMIT command saves all the transactions to the
database since the last COMMIT or ROLLBACK command.

The syntax for the COMMIT command is as follows.
Example: Consider the CUSTOMERS table having the following records

Following is an example which would delete those records from the table
which have age = 25 and then COMMIT the changes in the database.
Output: Thus, two rows from the table would be deleted and the SELECT
statement would produce the following result.

The ROLLBACK Command: The ROLLBACK command is the transactional command used to undo
transactions that have not already been saved to the database. This command can only be used to
undo transactions since the last COMMIT or ROLLBACK command was issued.
The syntax for a ROLLBACK command is as follows
Example: Consider the CUSTOMERS table having the following records

Following is an example, which would delete those records from the table
which have the age = 25 and then ROLLBACK the changes in the database.
Output
Thus, the delete operation would not impact the table and the SELECT statement would produce the following result.

The SAVEPOINT Command: A SAVEPOINT is a point in a transaction when you can roll the transaction back to a
certain point without rolling back the entire transaction.
The syntax for a SAVEPOINT command is as shown below.
This command serves only in the creation of a SAVEPOINT among all the transactional
statements. The ROLLBACK command is used to undo a group of transactions.
The syntax for rolling back to a SAVEPOINT is as shown below.
Following is an example where you plan to delete the three different records from the CUSTOMERS table. You
want to create a SAVEPOINT before each delete, so that you can ROLLBACK to any SAVEPOINT at any time to
return the appropriate data to its original state.

Example
Consider the CUSTOMERS table having the
following records.

The following code block contains the series of operations.

The following code block contains the series of operations.
Now that the three deletions have taken place, let us assume that you have
changed your mind and decided to ROLLBACK to the SAVEPOINT that you
identified as SP2. Because SP2 was created after the first deletion, the last two
deletions are undone

Output

Output
Notice that only the first deletion took place since you rolled back to SP2.

The RELEASE SAVEPOINT Command: The RELEASE SAVEPOINT command is used to
remove a SAVEPOINT that you have created.
The syntax for a RELEASE SAVEPOINT command is as follows.
Once a SAVEPOINT has been released, you can no longer use the ROLLBACK command
to undo transactions performed since the last SAVEPOINT.

The RELEASE SAVEPOINT Command: The RELEASE SAVEPOINT command is used to
remove a SAVEPOINT that you have created.
The syntax for a RELEASE SAVEPOINT command is as follows.
Once a SAVEPOINT has been released, you can no longer use the ROLLBACK command
to undo transactions performed since the last SAVEPOINT.
The SET TRANSACTION Command
The SET TRANSACTION command can be used to initiate a database transaction.
This command is used to specify characteristics for the transaction that follows.
For example, you can specify a transaction to be read only or read write.
Syntax
The syntax for a SET TRANSACTION command is as follows.

LOCK AND
UNLOCK TABLES
MySQL - LOCK TABLES Statement
You can restrict the access to records of the tables in MYSQL by locking them.
These locks are used to other sessions from modifying the tables in the current
session.
MySQL sessions can acquire or release locks on the table only for itself. To lock a
table using the MySQL LOCK TABLES Statement you need have the TABLE LOCK
and SELECT privileges.
These locks are used to solve the concurrency problems. There are two kinds of
MYSQL table locks
READ LOCK − If you apply this lock on a table the write operations on it are restricted.
i.e., only the sessions that holds the lock can write into this table.
WRITE LOCK − This lock allows restricts the sessions (that does not possess the lock)
from performing the read and write operations on a table.

Syntax: Following is the syntax of the MySQL LOCK TABLES Statement
Example: Suppose we have created a table that contains the sales details
along with the contact details of the customers as shown below

Now, let’s insert 2 records into the above created table using the
INSERT statement as

Now, let’s insert 2 records into the above created table using the
INSERT statement as
If we want another table with just the contact details of the
customer create a table as

Following queries insets records into the CustContactDetails table using the INSERT
INTO SELECT statement. Here, we are trying to insert records from the
SALES_DETAILS table to CustContactDetails table.
Here before the transfer, we are acquiring the write lock on the table to which we are
inserting records and acquiring read lock on the table from which we are inserting
records. Finally, after the transfer we are releasing the records.

Verification
You can verify the contents of the
CustContactDetails table as shown below

LOCK AND
UNLOCK TABLES
MySQL - UNLOCK TABLES Statement
A session releases all the tables locks with it at once. You can implicitly release the table
locks. If the connection to the server terminates explicitly or implicitly all the locks will be
released.
You can release the locks of a table explicitly using the UNLOCK TABLES statement.
Syntax
Following is the syntax of the MySQL UNLOCK TABLES statement

Now, let’s insert 2 records into the above
created table using the INSERT statement as

Now, let’s insert 2 records into the above
created table using the INSERT statement as
If we want another table with just the contact details of the customer create a table as

Following queries insets records into the CustContactDetails table using the
INSERT INTO SELECT statement. Here, we are trying to insert records from the
SALES_DETAILS table to CustContactDetails table.
Here before the transfer, we are acquiring the write lock on the table to which we
are inserting records and acquiring read lock on the table from which we are
inserting records. Finally, after the transfer we are releasing the records.

Verification
You can verify the contents of the CustContactDetails table as shown below

THE SCHEDULER
IN A DBMS, A SCHEDULER IS RESPONSIBLE FOR MANAGING THE
EXECUTION OF MULTIPLE TRANSACTIONS (I.E., OPERATIONS THAT
MODIFY THE DATABASE) THAT MAY BE RUNNING CONCURRENTLY. THE
SCHEDULER ENSURES THAT THE TRANSACTIONS EXECUTE IN A WAY
THAT MAINTAINS THE CONSISTENCY AND CORRECTNESS OF THE
DATABASE.
THE SCHEDULER TYPICALLY WORKS BY CONTROLLING ACCESS TO
SHARED RESOURCES, SUCH AS DATABASE TABLES AND INDEXES, TO
PREVENT CONFLICTS BETWEEN TRANSACTIONS. FOR EXAMPLE, IF TWO
TRANSACTIONS TRY TO MODIFY THE SAME DATA AT THE SAME TIME,
THE SCHEDULER WILL ENSURE THAT ONLY ONE OF THEM IS ALLOWED
TO PROCEED AT ANY GIVEN TIME.

CONCURRENCY
CONTROL WITH
LOCKING METHODS
CONCURRENCY CONTROL WITH LOCKING METHODS IS A TECHNIQUE
USED IN DATABASE MANAGEMENT SYSTEMS (DBMSS) TO ENSURE THAT
TRANSACTIONS DO NOT INTERFERE WITH EACH OTHER WHEN
ACCESSING SHARED RESOURCES, SUCH AS DATABASE TABLES OR ROWS.
THE BASIC IDEA BEHIND CONCURRENCY CONTROL WITH LOCKING
METHODS IS TO USE LOCKS TO PREVENT CONFLICTING TRANSACTIONS
FROM ACCESSING THE SAME RESOURCES SIMULTANEOUSLY. WHEN A
TRANSACTION NEEDS TO ACCESS A RESOURCE, IT MUST FIRST ACQUIRE A
LOCK ON THAT RESOURCE. ONCE THE TRANSACTION HAS FINISHED
USING THE RESOURCE, IT RELEASES THE LOCK SO THAT OTHER
TRANSACTIONS CAN ACCESS THE RESOURCE.

CONCURRENCY
CONTROL WITH
LOCKING METHODS
GUARANTEES EXCLUSIVE USE OF A DATA ITEM TO A CURRENT
TRANSACTION.
LOCK
INDICATES THE LEVEL OF LOCK USE.
LOCK GRANULARITY
ALL LOCK INFORMATION IS MANAGED BY A LOCKED MANAGER

CONCURRENCY
CONTROL WITH
LOCKING METHODS
DATABASE- LEVEL LOCK
THE ENTIRE DATABASE IS LOCKED
TABLE- LEVEL LOCK
THE ENTIRE TABLE IS LOCKED, PREVENTING ACCESS TO ANY BY
TRANSACTION T2 WHILE TRANSACTION T1 IS USING THE TABLE.
PAGE- LEVEL LOCK
THE DBMS WILL LOCK AN ENTIRE DISKPAGE. A DISKPAGE OR
PAGE IS THE EQUIVALENT OF A DISBLOCK.

CONCURRENCY
CONTROL WITH
LOCKING METHODS
PAGE-LEVEL LOCK
PAGE-LEVEL LOCKS ARE A TYPE OF LOCK USED IN DATABASE
MANAGEMENT SYSTEMS (DBMS) TO PROVIDE CONCURRENCY
CONTROL. INSTEAD OF LOCKING ENTIRE TABLES OR ROWS,
PAGE-LEVEL LOCKS ALLOW A DBMS TO LOCK ONLY A PORTION
OF A TABLE OR INDEX KNOWN AS A PAGE. A PAGE IS TYPICALLY
A FIXED-SIZE BLOCK OF DATA IN MEMORY OR ON DISK THAT
CONTAINS A SUBSET OF ROWS OR INDEX ENTRIES IN A TABLE
OR INDEX.

CONCURRENCY
CONTROL WITH
LOCKING METHODS
PAGE-LEVEL LOCK
WHEN A PAGE-LEVEL LOCK IS ACQUIRED, ONLY THE PAGE OR
PAGES THAT ARE BEING ACCESSED BY THE TRANSACTION ARE
LOCKED, NOT THE ENTIRE TABLE OR INDEX. THIS ALLOWS
OTHER TRANSACTIONS TO ACCESS OTHER PARTS OF THE TABLE
OR INDEX, IMPROVING CONCURRENCY.

CONCURRENCY
CONTROL WITH
LOCKING METHODS
ROW-LEVEL LOCK
ROW-LEVEL LOCKING CAN IMPROVE CONCURRENCY BY
ALLOWING MULTIPLE TRANSACTIONS TO ACCESS DIFFERENT
ROWS OF A TABLE CONCURRENTLY, WITHOUT LOCKING THE
ENTIRE TABLE. THIS CAN IMPROVE PERFORMANCE IN
SITUATIONS WHERE MULTIPLE USERS ARE ACCESSING A
DATABASE SIMULTANEOUSLY, SUCH AS IN A MULTI-USER
SYSTEM.

CONCURRENCY
CONTROL WITH
LOCKING METHODS
FIELD-LEVEL LOCK
FIELD-LEVEL LOCKING IS OFTEN USED IN SITUATIONS WHERE
ROWS IN A TABLE ARE VERY LARGE AND ONLY A SMALL SUBSET
OF FIELDS NEED TO BE MODIFIED BY A TRANSACTION. BY
LOCKING ONLY THE RELEVANT FIELDS, OTHER TRANSACTIONS
CAN CONTINUE TO READ OR MODIFY OTHER FIELDS OF THE
SAME ROW, REDUCING LOCK CONTENTION AND IMPROVING
CONCURRENCY.

CONCURRENCY
CONTROL WITH
LOCKING METHODS
*LOCK TYPES
BINARY LOCK
HAS ONLY TWO STATES: LOCKED(1) OR UNLOCKED(0). IF AN
OBJECT-THAT IS, DATABASE, TABLE, PAGE, OR ROW-IS LOCKED
BY A TRANSACTION, NO TRANSACTION CAN USE THAT OBJECT.
IF AN OBJECT IS UNLOCKED, ANY TRANSACTION CAN LOCKED
THE OBJECT FOR ITS USE.

CONCURRENCY
CONTROL WITH
LOCKING METHODS
*LOCK TYPES
SHARED/EXCLUSIVE LOCKS
THE LABELS "SHARED" AND "EXCLUSIVE" INDICATE THE NATURE
OF THE LOCK. AN EXCLUSIVE LOCKS EXISTS WHEN ACCESS IS
RESERVED SPECIFICALLY FOR THE TRANSACTION THAT LOCKED
THE OBJECT. A SHARED LOCK EXISTS WHEN CONCURRENT
TRANSACTION ARE GRANTED READ ACCESS ON THE BASIS OF
COMMON LOCK.

TWO-PHASE
LOCKING TO ENSURE
SERIALIZIBILITY
A GROWING PHASE, IN WHICH A TRANSACTION ACQUIRES ALL REQUIRED
LOCKS WITHOUT UNBLOCKING ANY DATA, ONCE ALL LOCKS HAVE BEEN
ACQUIRED, AND THE TRANSACTION IS IN ITS LOCKED POINT.
A SHRINKING PHASE, IN WHICH A TRANSACTION RELEASES ALL LOCKS AND
CANNOT OBTAIN ANY NEW LOCK.
TWO-PHASED LOCKING DEFINES HOW TRANSACTIONS
ACQUIRE AND RELINQUISH LOCK. TWO-PHASED
LOCKING GUARANTEES SERIALIZABILITY, BUT IT DOES
NOT PREVENT DEADLOCKS.
1.
2.

TWO TRANSACTIONS CANNOT HAVE CONFLICTING
LOCKS.
NO UNLOCK OPERATION CAN PRECEDE A LOCK
OPERATION IN THE SAME TRANSACTION.
NO DATA ARE AFFECTED UNTIL ALL LOCKS ARE
OBTAINED THAT IS, UNTIL THE TRANSACTION IS IN ITS
LOCKED POINT
THE TWO-PHASED LOCKING PROTOCOL IS GOVERNED BY
THE FOLLOWING RULES:
TWO-PHASED LOCKING INCREASES THE TRANSACTION
PROCESSING COST AND MIGHT CAUSE ADDITIONAL
UNDESIRABLE EFFECTS, ONE UNDESIRABLE EFFECT IS THE
POSSIBILITY OF CREATING DEADLOCKS

EXAMPLE:
NOTE – IF LOCK CONVERSION IS ALLOWED, THEN UPGRADING OF LOCK( FROM S(A) TO
X(A) ) IS ALLOWED IN THE GROWING PHASE, AND DOWNGRADING OF LOCK (FROM X(A) TO
S(A)) MUST BE DONE IN THE SHRINKING PHASE.
LET’S SEE A TRANSACTION IMPLEMENTING 2-PL.
THE GROWING PHASE IS FROM STEPS 1-3.
THE SHRINKING PHASE IS FROM STEPS 5-7.
LOCK POINT AT 3
THE GROWING PHASE IS FROM STEPS 2-6.
THE SHRINKING PHASE IS FROM STEPS 8-9.
LOCK POINT AT 6
THIS IS JUST A SKELETON TRANSACTION THAT
SHOWS HOW UNLOCKING AND LOCKING
WORK WITH 2-PL.
NOTE FOR:
TRANSACTION T1:
TRANSACTION T2:

HEY, WAIT!
WHAT IS LOCK POINT? THE POINT AT WHICH THE
GROWING PHASE ENDS, I.E., WHEN A TRANSACTION
TAKES THE FINAL LOCK IT NEEDS TO CARRY ON ITS
WORK. NOW LOOK AT THE SCHEDULE, YOU’LL SURELY
UNDERSTAND.
I HAVE SAID THAT 2-PL ENSURES SERIALIZABILITY, BUT
THERE ARE STILL SOME DRAWBACKS OF 2-PL. LET’S
GLANCE AT THE DRAWBACKS:

CASCADING ROLLBACK IS POSSIBLE UNDER 2-PL.
DEADLOCKS AND STARVATION ARE POSSIBLE.
CASCADING ROLLBACKS IN 2-PL –
LET’S SEE THE FOLLOWING SCHEDULE:

DEADLOCKS
DEADLOCKS
A DEADLOCK OCCURS WHEN TWO TRANSACTIONS WAIT
INDEFINITELY FOR EACH OTHER TO UNLOCK DATA. FOR
EXAMPLE, A DEADLOCK OCCURS WHEN TWO
TRANSACTIONS, T1 AND T2, EXIST IN THE FOLLOWING
MODE:
T1 = ACCESS DATA ITEMS X AND Y
T2 = ACCESS DATA ITEMS Y AND X
IF T1 HAS NOT UNLOCKED DATA ITEM Y, T2 CANNOT
BEGIN; IF T2 HAS NOT UNLOCKED DATA ITEM X, T1
CANNOT CONTINUE.
-

EXAMPLE:
IN A DATABASE, A DEADLOCK IS AN UNWANTED SITUATION IN WHICH TWO OR MORE
TRANSACTIONS ARE WAITING INDEFINITELY FOR ONE ANOTHER TO GIVE UP LOCKS.
DEADLOCK IS SAID TO BE ONE OF THE MOST FEARED COMPLICATIONS IN DBMS AS IT
BRINGS THE WHOLE SYSTEM TO A HALT.
EXAMPLE – LET US UNDERSTAND THE CONCEPT OF DEADLOCK WITH AN EXAMPLE :
SUPPOSE, TRANSACTION T1 HOLDS A LOCK ON SOME ROWS IN THE STUDENTS TABLE
AND NEEDS TO UPDATE SOME ROWS IN THE GRADES TABLE. SIMULTANEOUSLY,
TRANSACTION T2 HOLDS LOCKS ON THOSE VERY ROWS (WHICH T1 NEEDS TO
UPDATE) IN THE GRADES TABLE BUT NEEDS TO UPDATE THE ROWS IN THE STUDENT
TABLE HELD BY TRANSACTION T1.
NOW, THE MAIN PROBLEM ARISES. TRANSACTION T1 WILL WAIT FOR TRANSACTION T2
TO GIVE UP THE LOCK, AND SIMILARLY, TRANSACTION T2 WILL WAIT FOR
TRANSACTION T1 TO GIVE UP THE LOCK. AS A CONSEQUENCE, ALL ACTIVITY COMES
TO A HALT AND REMAINS AT A STANDSTILL FOREVER UNLESS THE DBMS DETECTS THE
DEADLOCK AND ABORTS ONE OF THE TRANSACTIONS.

CONCURRENCY
CONTROL WITH TIME
STAMPING METHODS
UNIQUENESS- ENSURES THAT NO EQUAL TIME STAMP VALUES
CAN EXIST.
MONOTONICITY- 1 ENSURES THAT TIME STAMP VALUES
ALWAYS INCREASE.
THE TIME STAMPING APPROACH TO SCHEDULING CONCURRENT
TRANSACTIONS ASSIGNS A GLOBAL, UNIQUE TIME STAMP TO EACH
TRANSACTION. THE TIME STAMP VALUE PRODUCES AN EXPLICIT
ORDER IN WHICH TRANSACTIONS ARE SUBMITTED TO THE DBMS.
TIME STAMPS MUST HAVE TWO PROPERTIES:

ONE FOR THE LAST TIME THE FIELD WAS READ AND ONE FOR
THE LAST UPDATE.
THE DISADVANTAGES OF THE TIME STAMPING APPROACH IS THAT
EACH VALUE STORED IN THE DATABASE REQUIRES TWO
ADDITIONAL TIME STAMP FIELDS:
TIME STAMPING THUS INCREASES MEMORY NEEDS AND
DATABASE'S PROCESSING OVERHEAD. TIME STAMPING DEMANDS
A LOT OF SYSTEM RESOURCES BECAUSE MANY TRANSACTIONS
MIGHT HAVE TO BE STOPPED, RESCHEDULED, AND RESTAMPED.

THE WAIT/ DIE SCHEME AND THE
WOUND/WAIT SCHEME
IF THE TRANSACTION REQUESTING THE LOCK IS THE
OLDER OF THE TWO TRANSACTIONS, IT WILL WAIT UNTIL
THE OTHER TRANSACTION IS COMPLETED AND THE LOCKS
ARE RELEASED.
YOUNGER OF THE TWO TRANSACTIONS, IT WILL DIE (ROLL
BACK AND IS RESCHEDULED) USING THE SAME TIME
STAMP.
USING THE WAIT/DIE SCHEME:

IF T5 REQUESTS A DATA ITEM HELD BY T10 THEN T5 WILL
"WAIT".
IF T15 REQUESTS A DATA ITEM HELD BY T10, THEN T15
WILL BE KILLED ("DIE").
THE WAIT/DIE SCHEME
EXAMPLE
SUPPOSE THAT TRANSACTION T5, T10, T15 HAVE TIME-
STAMPS 5, 10 AND 15 RESPECTIVELY.

WOUND/WAIT SCHEME
IF THE TRANSACTION REQUESTING THE LOCK IS THE OLDER
OF THE TWO TRANSACTIONS, IT WILL PREEMPT (WOUND)
THE YOUNGER TRANSACTION (BY ROLLING IT BACK). T1
PREEMPTS T2 WHEN TI ROLLS BACK T2. THE YOUNGER,
PREEMPTED TRANSACTION IS RESCHEDULED USING THE
SAME TIME STAMP.
YOUNGER OF THE TWO TRANSACTIONS, IT WILL WAIT UNTIL
THE OTHER TRANSACTION IS COMPLETED AND THE LOCKS
ARE RELEASED.
USING THE WOUND/DIE SCHEME:

IF T5 REQUESTS A DATA ITEM HELD BY T10, THEN DATA
ITEM WILL BE PREEMPTED FROM T10 AND T10 WILL BE
SUSPENDED. ("WOUNDED")
IF T15 REQUESTS A DATA ITEM HELD BY T10, THEN T15
WILL "WAIT".
THE WOUND/WAIT SCHEME
EXAMPLE
AGAIN, SUPPOSE THAT TRANSACTIONS T5, T10, T15 HAVE
TIME-STAMPS 5, 10 AND 15 RESPECTIVELY.

WOUND/WAIT SCHEME
OBVIOUSLY, THAT SCENARIO CAN CAUSE SOME
TRANSACTIONS TO WAIT INDEFINITELY, CAUSING A
DEADLOCK. TO PREVENT THAT TYPE OF DEADLOCK, EACH
LOCK REQUEST HAS AN ASSOCIATED TIME-OUT VALUE. IF THE
LOCK IS NOT GRANTED BEFORE THE TIME-OUT EXPIRES, THE
TRANSACTION IS ROLLED BACK.
IN BOTH SCHEMES, ONE OF THE TRANSACTIONS WAITS FOR THE
OTHER TRANSACTION TO FINISH AND RELEASE THE LOCKS.
HOWEVER, IN MANY CASES, A TRANSACTION REQUESTS MULTIPLE
LOCKS.
HOW LONG DOES A TRANSACTION HAVE TO WAIT FOR EACH
LOCK REQUEST?

CONCURRENCY
CONTROL WITH
OPTIMISTIC METHODS
THE OPTIMISTIC APPROACH IS BASED ON
THE ASSUMPTION THAT THE MAJORITY OF
THE DATABASE OPERATIONS DO NOT
CONFLICT.
THE OPTIMISTIC APPROACH REQUIRES
NEITHER LOCKING NOR TIME STAMPING
TECHNIQUES.

DURING THE READ PHASE, THE TRANSACTION READS THE
DATABASE, EXECUTES THE NEEDED COMPUTATIONS, AND
MAKES THE UPDATES TO A PRIVATE COPY OF THE
DATABASE VALUES.
DURING THE VALIDATION PHASE, THE TRANSACTION IS
VALIDATED TO ENSURE THAT THE CHANGES MADE WILL
NOT AFFECT THE INTEGRITY AND CONSISTENCY OF THE
DATABASE.
DURING THE WRITE PHASE, THE CHANGES ARE
PERMANENTLY APPLIED TO THE DATABASE.

The following tables follow an example:
At 1:00 p.m., User1 reads a row from the database with the following values:
CustID LastName FirstName
101 Smith Bob
Users who use optimistic concurrency do not lock a row when reading it. When a
user wants to update a row, the application must determine whether another user
has changed the row since it was read.

At 1:01 p.m., User2 reads the same row.
At 1:03 p.m., User2 changes FirstName from "Bob" to "Robert" and
updates the database.

The update succeeds because the values in the database at the time of
update match the original values that User2 has.
At 1:05 p.m., User1 changes "Bob"'s first name to "James" and tries to
update the row.

Group-2.pdf

Recommended

Recommended

More Related Content

Similar to Group-2.pdf

Similar to Group-2.pdf (20)

Recently uploaded

Recently uploaded (20)

Group-2.pdf