Chapter 3

Transaction Processing Concepts

CoSc 266 : Advanced Database management System
Instructor : Shewakena G.
 Chapter 3 Outline
• Introduction to Transaction Processing
• Transaction and System Concepts
• Desirable Properties of Transactions
• Schedules and Recoverability
• Serializability of Schedules
 Introduction to Transaction Processing

• Transaction: An executing program (process) that includes one or more database

access operations.
• Ensures that related data is added to or deleted from the database
simultaneously, thus preserving data integrity in your application.
– Read operations (database retrieval, such as SQL SELECT)
– Write operations (modify database, such as SQL INSERT, UPDATE, DELETE)
– Transaction: A logical unit of database processing
– Example: Bank balance transfer of $100 dollars from a checking account to a saving account in a
BANK database
• Note: Each execution of a program is a distinct transaction with different parameters
– Bank transfer program parameters: savings account number, checking account number, transfer
amount
 Introduction to Transaction Processing

• A transaction (set of operations) may be:

– stand-alone, specified in a high level language like SQL
submitted interactively, or
– consist of database operations embedded within a program (most
transactions)
• Transaction boundaries: Begin and End transaction.
– Note: An application program may contain several transactions
separated by Begin and End transaction boundaries
 Introduction to Transaction Processing (cont.)

Transaction Processing Systems

 Single-User System:
At most one user at a time can use the system. E.g. pc, mobile.
 Multiuser System:
Many users can access the system concurrently.
Multiple program/process can execute at the same time. e.g. Bank
• Two Modes of Concurrency
 Concurrency: allows many concurrent user to access the database.
– Interleaved processing: concurrent execution of processes is interleaved in a
single CPU. E.g. round robin algorithm.
– Parallel processing: processes are concurrently executed in multiple CPUs
 Introduction to Transaction Processing (cont.)

Reading Ass:
Discuss on Advantages and disadvantages of both processes?
 Introduction to Transaction Processing

Types of Transaction
 Read-only transaction: A transaction operation that do not update the database but only retrieve data
from the database.
 Read-Write transaction: A transaction operation that perform the update operation in addition to
retrieval of database data.
For transaction processing purposes, a simple database model is used:
• A database - collection of named data items
• Granularity (size) of a data item - a field (data item value), a record, or a whole disk block
– TP concepts are independent of granularity

• Basic operations on an item X:

– read_item(X): Reads a database item named X into a program variable. To simplify our notation, we assume
that the program variable is also named X.
– write_item(X): Writes the value of program variable X into the database item named X.
 Introduction to Transaction Processing

READ AND WRITE OPERATIONS:

 Read operation reads the data from the database and then stores it in the buffer in main
memory.
 A data item X (what is read or written) will usually be the field of some record in the
database, although it may be a larger unit such as a whole record or even a whole block.
 Read_item(X) command includes the following steps:
1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if that disk block is not already
in some main memory buffer).
3. Copy item X from the buffer to the program variable named X.
 Introduction to Transaction Processing
READ AND WRITE OPERATIONS (cont.):
 Write operation writes the updated data value back to the database from the buffer.
 write_item(X) command includes the following steps:
1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if it is not already in
some main memory buffer).
3. Copy item X from the program variable named X into its correct location in
the buffer.
4. Store the updated block from the buffer back to disk (either immediately or
at some later point in time).
 Transaction Notation

• Two simple examples of transactions.

• Can also write in shorthand notation:
– T1: b1; r1(X); w1(X); r1(Y); w1(Y); e1;
– T2: b2; r2(X); w2(X); e2;
• bi and ei specify transaction boundaries (begin and end)
• i specifies a unique transaction identifier (TId)
 Why we need concurrency control
 Concurrency Control: is a procedure of managing simultaneous transactions ensuring
their atomicity, isolation, consistency, and serializability.
 Several problems that arise when numerous transactions execute simultaneously in a
random manner are referred to as concurrency control problems.
 Without Concurrency Control, problems may occur with concurrent transactions.
The following are the main Concurrency transactions problems :
1. Lost Update Problem(Write-Write conflict):
 Occurs when two transactions update the same data item, but both read the same original value before
update (see figure a in the next slide)
 Update made by one transaction is overridden by another transaction.
2. The Temporary Update (or Dirty Read/ Write-Read conflict) Problem.
 This occurs when one transaction T1 updates a database item X, which is accessed (read) by another
transaction T2; then T1 fails for some reason (see figure b in the next slide); X was (read) by T2 before its
value is changed back (rolled back or UNDONE) after T1 fails
 Why we need concurrency control

3. The Incorrect Summary Problem:

 One transaction is calculating an aggregate summary function on a number of
records (for example, sum (total) of all bank account balances) while other
transactions are updating some of these records
 For example, transferring a large amount between two accounts, (see figure c in
the next slide ); the aggregate function may read some values before they are
updated and others after they are updated.
 Why we need concurrency control?

4. The Unrepeatable Read Problem .

 A transaction T1 may read an item (say, available seats on a flight); later, T1
may read the same item again and get a different value because another
transaction T2 has updated the item (reserved seats on the flight) between
the two reads by T1.
For example
 During an airline reservation transaction, a customer inquires about seat
availability on several flights.
 When the customer decides on a particular flight, the transaction then reads
the number of seats on that flight a second time before completing the
reservation, and it may end up reading a different value for the item.
 Why recovery is needed?

 Whenever a transaction is submitted to a DBMS for execution,

 The system is responsible for making sure that either all the
operations in the transaction are completed successfully and their
effect is recorded permanently in the database, or that the transaction
does not have any effect on the database or any other transactions.
 In the first case, the transaction is said to be committed, whereas in
the second case, the transaction is aborted.
 If the transaction is aborted, there is failure. The operations already
executed must be undone and have no lasting effect.
 Why recovery is needed?

Causes of transaction failure:

1. A computer failure (system crash):
 A hardware or software error occurs during transaction execution. If the hardware crashes, the contents
of the computer’s internal main memory may be lost.

2. A transaction or system error :

 Some operation in the transaction may cause it to fail, such as integer overflow
or division by zero.
 Transaction failure may also occur because of erroneous parameter values or
because of a logical programming error.
 In addition, the user may interrupt the transaction during its execution.
 Why recovery is needed (cont.)

3. Local errors or exception conditions detected by the transaction:

 Certain conditions necessitate cancellation of the transaction.
 For example, data for the transaction may not be found. A condition, such as
insufficient account balance in a banking database, may cause a transaction,
such as a fund withdrawal, to be canceled - a programmed abort causes the
transaction to fail.
4. Concurrency control enforcement:
 The concurrency control method may decide to abort the transaction, to be
restarted later, because it violates serializability or because several
transactions are in a state of deadlock.
 serializability is a property of a system describing how different processes operate on
shared data.
 Why recovery is needed (cont.)
5. Disk failure:
 Some disk blocks may lose their data because of a read or write
malfunction or because of a disk read/write head crash.
 This kind of failure and item 6 are more severe than items 1
through 4.
6. Physical problems and catastrophes:
 This refers to an endless list of problems that includes power or air-
conditioning failure, fire, theft, sabotage, overwriting disks or tapes
by mistake, and mounting of a wrong tape by the operator.
 Why recovery is needed (cont.)

 Failures of types 1, 2, 3, and 4 are more common than those

of types 5 or 6. Whenever a failure of type 1 through 4
occurs, the system must keep sufficient information to
quickly recover from the failure.
 Disk failure or other catastrophic failures of type 5 or 6 do
not happen frequently; if they do occur, recovery is a major
task.
(We discuss recovery from failure in Chapter 6).
 Transaction and System Concepts

 A transaction is an atomic unit of work that is either completed in its entirety or not done
at all.
For recovery purposes, the system needs to keep track of when each transaction starts,
terminates, and commits or aborts.
 A transaction passes through several states (see figure in the next slide).
Transaction states:
 Active state (executing read, write operations/beginning of transaction execution)
 Partially committed state (ended but waiting for system checks to determine success
or failure/not ensure permanent modification on DB.)
 It is only saved on buffer/temporary memory.
 Committed state (transaction succeeded/changes done persistently)
 Failed state (transaction failed, must be rolled back/aborted during active state or if
one rechecking is fails.)
 Terminated State (transaction leaves system)
Transaction and System Concepts
 Transaction and System Concepts (cont.)

DBMS Recovery Manager needs system to keep track of the following operations
(in the system log file):
• Begin_transaction: beginning of transaction execution.
• Read or write: Read or write operations on the database items that are executed
as part of a transaction.
• End_transaction: Specifies end of read and write transaction operations have
ended.
• System may still have to check whether the changes (writes) introduced by
transaction can be permanently applied to the database (commit transaction);
or whether the transaction has to be rolled back (abort transaction) because it
violates concurrency control or for some other reason.
 Transaction and System Concepts (cont.)

Recovery manager keeps track of the following operations (cont:)

• Commit_transaction: Signals successful end of transaction; any changes
(writes) executed by transaction can be safely committed to the database and
will not be undone.
• Abort_transaction (or rollback): Signals transaction has ended
unsuccessfully; any changes or effects that the transaction may have applied
to the database must be undone.
 Transaction and System Concepts (cont.)

System operations used during recovery (will be covered in chapter 6):

• undo(X): Similar to rollback except that it applies to a single write
operation rather than to a whole transaction.
• redo(X): This specifies that a write operation of a committed
transaction must be redone to ensure that it has been applied
permanently to the database on disk.
 Transaction and System Concepts (cont.)

The System Log File

 Is an append-only file to keep track of all operations of all transactions in the order in
which they occurred. This information is needed during recovery from failures
 Log is kept on disk - not affected except for disk or catastrophic failure
 As with other disk files, a log main memory buffer is kept for holding the records being
appended until the whole buffer is appended to the end of the log file on disk
 Log is periodically backed up to archival storage (tape) to guard against catastrophic
failures
 protocols for recovery that avoid cascading rollbacks do not require that read
operations be written to the system log; most recovery protocols fall in this category.
 strict protocols require simpler write entries that do not include new_value.
 Transaction and System Concepts (cont.)

Types of records (entries) in log file:

 [start_transaction,T]: Records that transaction T has started
execution.
 [write_item,T,X,old_value,new_value]: T has changed the value of
item X from old_value to new_value.
 [read_item,T,X]: T has read the value of item X (not needed in
many cases).
 [end_transaction,T]: T has ended execution
 [commit,T]: T has completed successfully, and committed.
 [abort,T]: T has been aborted.
 Transaction and System Concepts (cont.)

Commit Point of a Transaction:

 Definition: A transaction T reaches its commit point when
all its operations that access the database have been
executed successfully and the effect of all the transaction
operations on the database has been recorded in the log file
(on disk). The transaction is then said to be committed.
 Transaction and System Concepts (cont.)

Commit Point of a Transaction (cont.):

 Log file buffers: Like database files on disk, whole disk blocks must be read or written to main
memory buffers.
 For log file, the last disk block (or blocks) of the file will be in main memory buffers to easily append
log entries at end of file.
 Force writing the log buffer: before a transaction reaches its commit point, any main memory
buffers of the log that have not been written to disk yet must be copied to disk.
 Called force-writing the log buffers before committing a transaction.
 Needed to ensure that any write operations by the transaction are recorded in the log file on disk before
the transaction commits
 Desirable Properties of Transactions

Transactions should possess several properties, often called the ACID properties – Atomicity,
Consistency, Isolation, Durability:
► Atomicity: A transaction is an atomic unit of processing; it is either performed in its
entirety or not performed at all.
► Atomicity involves the following two operations:
► Abort: If a transaction aborts then all the changes made are not visible.
► Commit: If a transaction commits then all the changes made are visible.
► Consistency : A correct execution of the transaction must take the database from one
consistent state to another.
– The integrity constraints are maintained so that the database is consistent before and
after the transaction.
– The execution of a transaction will leave a database in either its prior stable state or a
new stable state.
 Desirable Properties of Transactions (cont.)

ACID properties (cont.):

• Isolation: It shows that the data which is used at the time of execution of a transaction
cannot be used by the second transaction until the first one is completed.
– In isolation, if the transaction T1 is being executed and using the data item X, then that
data item can't be accessed by any other transaction T2 until the transaction T1 ends.
– The concurrency control subsystem of the DBMS enforced the isolation property.
• Durability or permanency: Once a transaction is committed, its changes (writes) applied
to the database must never be lost because of subsequent failure.
• The durability property is used to indicate the performance of the database's consistent
state. It states that the transaction made the permanent changes.
– That consistent state cannot be lost, even in the event of a system's failure.
– The recovery subsystem of the DBMS has the responsibility of Durability property.
 Desirable Properties of Transactions (cont.)

• Atomicity: Enforced by the recovery protocol. It is the responsibility

of the transaction recovery subsystem of a DBMS to ensure atomicity
• Consistency preservation: Specifies that each transaction does a
correct action on the database on its own. Application programmers
and DBMS constraint enforcement are responsible for this.
• Isolation: Responsibility of the concurrency control protocol.

• Durability or permanency: Enforced by the recovery protocol.

 Schedules of Transactions

• Transaction schedule (or history): When transactions are executing

concurrently in an interleaved fashion, the order of execution of operations from
the various transactions forms what is known as a transaction schedule (or
history).
• Figure in the next slide shows 4 possible schedules (A, B, C, D) of two
transactions T1 and T2:
– Order of operations from top to bottom
– Each schedule includes same operations
– Different order of operations in each schedule
 Schedules of Transactions (cont.)

• Schedules can also be displayed in more compact notation

• Order of operations from left to right
• Include only read (r) and write (w) operations, with transaction id (1, 2, …)
and item name (X, Y, …)
• Can also include other operations such as b (begin), e (end), c (commit), a
(abort)
• Schedules in the figure above slide would be displayed as follows:
– Schedule A: r1(X); w1(X); r1(Y); w1(Y); r2(X); w2(x);
– Schedule B: r2(X); w2(X); r1(X); w1(X); r1(Y); w1(Y);
– Schedule C: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);
– Schedule D: r1(X); w1(X); r2(X); w2(X); r1(Y); w1(Y);
 Schedules of Transactions (cont.)

• Formal definition of a schedule (or history) S of n transactions T1,

T2, ..., Tn :
• An ordering of all the operations of the transactions subject to the
constraint that, for each transaction Ti that participates in S, the
operations of Ti in S must appear in the same order in which they
occur in Ti.
Note: Operations from other transactions Tj can be interleaved with
the operations of Ti in S.
 Schedules of Transactions (cont.)

Conflict of Schedule
• Two operations in a schedule are said to conflict if they satisfy all three of the following
conditions:
1. They belong to different transactions
2. They access the same item X and
3. At least one of the operations is a write_item(X).

Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);

For example, In schedule Sa, the operations
 r1(X) and w2(X) , r2(X) and w1(X), and w1(X) and w2(X) are conflict schedule.
However,
 r1(X) and r2(X) do not conflict, since they are both read operations;
 w2(X) and w1(Y) do not conflict because they operate on distinct data items X and Y; and
 r1(X) and w1(X) do not conflict because they belong to the same transaction.
 Schedules of Transactions (cont.)

• The rest of this section covers some theoretical definitions concerning schedules.
• A schedule S of n transactions T1, T2, ..., Tn is said to be a complete schedule if
the following conditions hold:
1. The operations in S are exactly those operations in T1,T2,...,Tn, including a
commit or abort operation as the last operation for each transaction in the
schedule.
2. For any pair of operations from the same transaction T i, their relative order of
appearance in S is the same as their order of appearance in T i.
3. For any two conflicting operations, one of the two must occur before the
other in the schedule.
• Rest of chapter characterizes schedules by classifying them based on ease of
recovery (recoverability) and correctness (serializability)
 Characterizing Schedules based on Recoverability

Schedules classified into two main classes:

• Recoverable schedule: One where no committed transaction needs to be rolled back
(aborted).
A schedule S is recoverable if no transaction T in S commits until all transactions T’
that have written an item that T reads have committed.
• Non-recoverable schedule: A schedule where a committed transaction may have to
be rolled back during recovery.
This violates Durability from ACID properties (a committed transaction cannot be
 Characterizing Schedules Based on Recoverability (cont.)

• Example: Schedule A below is non-recoverable because T2 reads the

value of X that was written by T1, but then T2 commits before T1 commits
or aborts
• To make it recoverable, the commit of T2 (c2) must be delayed until T1
either commits, or aborts (Schedule B)
• If T1 commits, T2 can commit
• If T1 aborts, T2 must also abort because it read a value that was written by
T1; this value must be undone (reset to its old value) when T1 is aborted
– known as cascading rollback
• Schedule A: r1(X); w1(X); r2(X); w2(X); c2; r1(Y); w1(Y); c1 (or a1)
• Schedule B: r1(X); w1(X); r2(X); w2(X); r1(Y); w1(Y); c1 (or a1); ...
 Characterizing Schedules based on Recoverability
(cont.)

Recoverable schedules can be further refined:

 Cascadeless schedule: A schedule in which a transaction T2
cannot read an item X until the transaction T1 that last
wrote X has committed.
 The set of cascadeless schedules is a subset of the set of
recoverable schedules.
 Schedules requiring cascaded rollback: A schedule in which
an uncommitted transaction T2 that read an item that was
written by a failed transaction T1 must be rolled back.
 Characterizing Schedules Based on Recoverability
(cont.)
• Example: Schedule B below is not cascadeless because T2
reads the value of X that was written by T1 before T1
commits
• If T1 aborts (fails), T2 must also be aborted (rolled back)
resulting in cascading rollback
• To make it cascadeless, the r2(X) of T2 must be delayed until
T1 commits (or aborts and rolls back the value of X to its
previous value) – see Schedule C

• Schedule B: r1(X); w1(X); r2(X); w2(X); r1(Y); w1(Y); c1 (or a1);

• Schedule C: r1(X); w1(X); r1(Y); w1(Y); c1; r2(X); w2(X); ...
 Characterizing Schedules based on
Recoverability (cont.)
Cascadeless schedules can be further refined:
• Strict schedule: A schedule in which a transaction T2 can neither read
nor write an item X until the transaction T1 that last wrote X has
committed.
• The set of strict schedules is a subset of the set of cascadeless
schedules.
• If blind writes are not allowed, all cascadeless schedules are also strict

Blind write: A write operation w2(X) that is not preceded by a read

r2(X).
 Characterizing Schedules Based on Recoverability
(cont.)
• Example: Schedule C below is cascadeless and also strict
(because it has no blind writes)
• Schedule D is cascadeless, but not strict (because of the
blind write w3(X), which writes the value of X before T1
commits)
• To make it strict, w3(X) must be delayed until after T1
commits – see Schedule E

• Schedule C: r1(X); w1(X); r1(Y); w1(Y); c1; r2(X); w2(X); …

• Schedule D: r1(X); w1(X); w3(X); r1(Y); w1(Y); c1; r2(X); w2(X); …
• Schedule E: r1(X); w1(X); r1(Y); w1(Y); c1; w3(X); r2(X); w2(X); …
 Characterizing Schedules Based on Recoverability
(cont.)
Summary:
• Many schedules can exist for a set of transactions
• The set of all possible schedules can be partitioned into
two subsets: recoverable and non-recoverable
• A subset of the recoverable schedules are cascadeless
• If blind writes are allowed, a subset of the cascadeless
schedules are not strict
• If blind writes are not allowed, the set of cascadeless
schedules is the same as the set of strict schedules
 Characterizing Schedules based on Serializability
• Among the large set of possible schedules, we want to
characterize which schedules are guaranteed to give a
correct result
• The consistency preservation property of the ACID
properties states that: each transaction if executed on its
own (from start to finish) will transform a consistent
state of the database into another consistent state
• Hence, each transaction is correct on its own
 Characterizing Schedules based on Serializability (cont.)

• Serial schedule: A schedule S is serial if, for every transaction

T participating in the schedule, all the operations of T are
executed consecutively (without interleaving of operations
from other transactions) in the schedule. Otherwise, the
schedule is called non-serial. (see the figure in the next slide)

• Based on the consistency preservation property, any serial

schedule will produce a correct result (assuming no inter-
dependencies among different transactions)
Characterizing Schedules based on Serializability (cont.)
 Characterizing Schedules based on Serializability
(cont.)
If the schedule is a serial one and if no interleaving of operations is
permitted, there are only two possible outcomes:
1. Execute all the operations of transaction T1 (in sequence) followed by all
the operations of transaction T2 (in sequence).
2. Execute all the operations of transaction T2 (in sequence) followed by all
the operations of transaction T1 (in sequence).
These two schedules—called serial schedules—are shown in
Figure (a) and (b) above, respectively.
If interleaving of operations is allowed, there will be many
possible orders in which the system can execute the individual
operations of the transactions.
 Characterizing Schedules based on Serializability
(cont.)
• Serial schedules are not feasible for performance reasons:
– No interleaving of operations
– Long transactions force other transactions to wait
– System (CPU) cannot switch to other transaction
when a transaction is waiting for disk I/O or any other
event, thus wasting valuable CPU processing time
 Need to allow concurrency with interleaving without
sacrificing correctness
 Characterizing Schedules based on Serializability (cont.)
• Serializability of schedules
The concept of serializability of schedules is used to identify which
schedules are correct when transaction executions have interleaving of
their operations in the schedules.
• Serializable schedule: A schedule S is serializable if it is
equivalent to some serial schedule of the same n transactions.
• There are (n)! serial schedules for n transactions – a serializable
schedule can be equivalent to any of the serial schedules.
• The objective is to determine which of the nonserial schedules
always give a correct result and which may give erroneous results
• Question: How do we define equivalence of schedules?
 Characterizing Schedules based on Serializability (cont.)
• Serializability of schedules
– A schedule S of n transactions is serializable if it is equivalent
to some serial schedule of the same n transactions. In the
figure bellow, a and b are serial schedule but D is non serial
schedule. a and d gives the same result
 Equivalence of Schedules
• Result equivalent: Two schedules are called result
equivalent if they produce the same final state of the
database.
• Difficult to determine without analyzing the internal
operations of the transactions, which is not feasible in
general.
• May also get result equivalence by chance for a particular
input parameter even though schedules are not
equivalent in general
 Equivalence of Schedules (cont.)
• Conflict equivalent: Two schedules are conflict equivalent if the
relative order of any two conflicting operations is the same in both
schedules.
• Commonly used definition of schedule equivalence
• Two operations are conflicting if:
– They access the same data item X
– They are from two different transactions
– At least one is a write operation
• Read-Write conflict example: r1(X) and w2(X)
• Write-write conflict example: w1(Y) and w2(Y)
 Equivalence of Schedules (cont.)
• Changing the order of conflicting operations generally
causes a different outcome
• Example: changing r1(X); w2(X) to w2(X); r1(X) means
that T1 will read a different value for X
• Example: changing w1(Y); w2(Y) to w2(Y); w1(Y) means
that the final value for Y in the database can be different
• Note that read operations are not conflicting; changing
r1(Z); r2(Z) to r2(Z); r1(Z) does not change the outcome
 Characterizing Scedules Based on Serializability
(cont.)

• Conflict equivalence of schedules is used to determine

which schedules are correct in general (serializable)

A schedule S is said to be serializable if it is conflict

equivalent to some serial schedule S’.
 Characterizing Schedules based on Serializability
(cont.)
• A serializable schedule is considered to be correct because it is
equivalent to a serial schedule, and any serial schedule is
considered to be correct
– It will leave the database in a consistent state.

– The interleaving is appropriate and will result in a state as if the

transactions were serially executed, yet will achieve efficiency due to
concurrent execution and interleaving of operations from different
transactions.
 Characterizing Schedules based on
Serializability (cont.)
• Serializability is generally hard to check at run-time:
– Interleaving of operations is generally handled by
the operating system through the process scheduler
– Difficult to determine beforehand how the
operations in a schedule will be interleaved
– Transactions are continuously started and
terminated
 Characterizing Schedules Based on Serializability (cont.)

Practical approach:
• Come up with methods (concurrency control protocols)
to ensure serializability (discussed in Chapter 6)
• DBMS concurrency control subsystem will enforce the
protocol rules and thus guarantee serializability of
schedules
• Current approach used in most DBMSs:
– Use of locks with two phase locking (see chpter 6)
Characterizing Schedules based on Serializability (cont.)
Testing for conflict serializability Algorithm
• Looks at only r(X) and w(X) operations in a schedule
• Constructs a precedence graph (serialization graph) – one
node for each transaction, plus directed edges
• An edge is created from Ti to Tj if one of the operations in Ti
appears before a conflicting operation in Tj
• The schedule is serializable if and only if the precedence graph
has no cycles.
Characterizing Schedules based on Serializability (cont.)
End of Chapter
Thank You!