MWENGE CATHOLIC UNIVERSITY

DEPARTMENT OF NATURAL SCIENCE AND INFORMSTION TECHNOLOGY

COURSE NAME : DBMS

COURSE CODE: CSC 215
TASK: INDIVIDUAL ASSIGNMENT
COURSE INSTRUCTOR: R. MNYAWI

S/n NAME REG NO

1. PAUL ALPHONCE T/DEG/2020/1366
Qn 1. Characteristics of a Modern DBMS

DBMSs have been developed to resolve the limitations of traditional data management systems.
Here are 10 key characteristics of a modern DBMS:

Data Integrity: DBMS ensures data accuracy and consistency, which is crucial for maintaining correct
information in multi-user environments.

 Data Security: It provides mechanisms to restrict unauthorized access and protect

sensitive data, which can include encryption and access control mechanisms.
 Data Redundancy Control: DBMS minimizes data duplication by organizing data in
a normalized form, thus saving storage and improving data consistency.
 Data Independence: Applications can access data without knowing its structure, as
DBMS abstracts the storage details.
 Backup and Recovery: DBMS supports automatic backups and the ability to restore
databases after accidental data loss, ensuring data availability.
 Concurrency Control: DBMS allows multiple users to access and modify data
simultaneously while maintaining data consistency and isolation.
 Transaction Management: DBMS uses transactions to ensure that a series of
database operations are completed successfully, ensuring data reliability.
 Multi-User Support: DBMS enables multiple users to interact with the database at
the same time by isolating user transactions.
 Data Abstraction: DBMS hides the complexity of data storage, allowing users to
work with data on a logical level without needing to understand physical storage.
 Scalability: Modern DBMS systems can handle an increasing amount of data and
users as organizations grow.

Qn2. Concept of Database Architecture

Database architecture defines the framework that outlines how data is managed, stored, and
accessed within a database system. The architecture is typically layered to separate user
interactions, application logic, and data management, ensuring system efficiency and
flexibility. Common components include:

 Database Server: Manages data storage, querying, and transactions.

 Client Interface: Where users interact with the database, either via applications or
SQL.
 Middleware: Manages requests between the client and server, especially in multi-tier
architectures.

 3. One-tier Architecture:
o All elements are on a single system; commonly used for simple, standalone
applications.
o Diagram: Show a single layer with the database and application on the same
level.
  Two-tier Architecture:
o Involves a client and a server. The client interacts with the database via direct
SQL queries.
o Common in applications with a direct connection to the database, such as
desktop applications.
o Diagram: Show client and database on two separate layers.
 Three-tier Architecture:
o Consists of three layers: the presentation (client), application (middleware),
and database (server).
o Supports complex applications, typically web-based, where the application
layer handles business logic.
o Diagram: Show three layers with client, application server, and database
server.

Qn 3. Detailed description of one-tier, two-tier, and three-tier database architectures,

along with diagrams for each.

a. One-Tier Database Architecture

In one-tier architecture, the database, application logic, and user interface are all located on
the same system. This architecture is commonly used in standalone, personal applications
where the user directly interacts with the database on a local machine. Since all components
are on a single device, there’s no network communication required, making it fast but
limiting its scalability and suitability for multi-user environments.

Key Characteristics:

 Database, application, and user interface are on one system.

 Direct data access with minimal security or concurrency control.
 Commonly used for simple, single-user applications.

Diagram:
sql
Copy code
+---------------------+
| Application |
| (Database + Logic + |
| User Interface) |
+---------------------+

b. Two-Tier Database Architecture

In two-tier architecture, the database server and client application are separated across two
different systems, usually connected through a network. The client (front-end) application
communicates directly with the database server (back-end) to send queries and retrieve data.
This setup allows remote access to data and is used for small to medium-sized applications,
like business applications where multiple users access a central database.

Key Characteristics:

 Divides the system into Client (Application) and Server (Database).

 Client application sends SQL queries directly to the database server.
 Often used in client-server applications for moderate scalability.

Diagram:
arduino
Copy code
Client Side Server Side
+---------------+ +---------------+
| Client | | Database |
| Application | <---- Network ----> | Server |
+---------------+ +---------------+

c. Three-Tier Database Architecture

Three-tier architecture introduces a middle layer (application or middleware layer) between

the client and database, which contains the application logic. This middle layer handles the
processing of business rules, application logic, and data requests, making the architecture
more modular and secure. The three layers are:

1. Presentation Layer (Client): The user interface, like a web browser or desktop
application.
2. Application Layer (Middleware): Contains the business logic and processes data
requests.
3. Database Layer (Server): Manages data storage and retrieval.

This architecture is highly scalable and is ideal for complex applications, such as web
applications or enterprise systems, where multiple users access a database through a secure,
multi-layered process.

Key Characteristics:

 Divides system into Client, Application Layer (Middleware), and Database

Server.
 Enhances scalability, flexibility, and security by isolating data, logic, and interface.
 Commonly used in large-scale, distributed systems.
Diagram:
arduino
Copy code
Client Side Middleware Server Side
+--------------+ +--------------+ +--------------+
| Client UI | <-----> | Application | <-------> | Database |
| (Web Browser)| | Server | | Server |
+--------------+ +--------------+ +--------------+

Qn4. a. ODBC vs. JDBC

JDBC (Java Database
Aspect ODBC (Open Database Connectivity)
Connectivity)

A standard API for accessing database A Java API specifically designed

Definition
management systems (DBMS) for connecting to databases

Platform Java-specific and primarily used

Platform-independent, works on any OS
Dependency on JVM-supported platforms

Language Primarily used with languages like C, C++ Only for Java applications

Uses JDBC drivers, which

Driver Types Uses ODBC drivers include various types (Type-1 to
Type-4)

Setup Requires the ODBC driver manager to be Works directly with JDBC
Requirements installed on the system drivers in Java applications

May be slower on Java platforms due to Optimized for Java applications;

Performance
extra layer in communication generally faster within the JVM

Primarily intended for Java

General use across various programming
Usage Scope programs connecting to
languages and applications
databases

b. Procedural vs. Non-Procedural DML

Aspect Procedural DML Non-Procedural DML

Specifies how to perform operations on Specifies what data to retrieve or

Definition
the data manipulate

PL/SQL (Procedural
Examples Language/Structured Query Language), SQL (Structured Query Language)
T-SQL

Gives explicit control over how queries Focuses only on desired outcomes
Control
are processed without specifying procedures
Aspect Procedural DML Non-Procedural DML

Generally more complex and requires Simpler to write as it doesn’t require

Complexity
knowledge of programming logic control-flow commands

Common Useful for complex tasks like loops, Used for straightforward querying
Usage conditional statements, and transactions and data manipulation

Execution Can be slower if complex logic adds Often faster since the database
Speed overhead engine optimizes the operations

Running basic CRUD operations like

Use Case Creating stored procedures or triggers
SELECT, INSERT, UPDATE,
Example that involve control flow
DELETE

Qn5 a. Centralized Database

 Definition: A centralized database is a single database located and maintained at one

central location, often within a single computer system or data center.
 Characteristics:
o All data storage, management, and control take place in one central location.
o Accessed over a network by various users or applications.
 Advantages:
o Easier to manage and control data integrity, security, and consistency.
o Simplified backup and recovery processes.
 Disadvantages:
o Potential for a single point of failure; if the central server is down, no one can
access the data.
o Limited scalability and potential performance bottlenecks due to centralized
processing.

b. Client-Server Database

 Definition: A client-server database divides the database application into two parts:
the client (front-end) and the server (back-end). The client typically handles the user
interface and interacts with the server, which manages data storage and processing.
 Characteristics:
o Clients send requests to the server, which processes data and returns results.
o Data management, storage, and processing are handled by the server, while the
client handles user interactions.
 Advantages:
o Improved security and centralized control of the database on the server side.
o Better performance and reliability for multi-user environments.
 Disadvantages:
o Requires network infrastructure, which could introduce latency.
 o Potential for server overload if too many clients access it simultaneously.

c. Parallel Database

 Definition: A parallel database system uses multiple processors and/or storage

devices working together to perform database operations concurrently, effectively
distributing the workload.
 Characteristics:
o Supports parallel processing by splitting large tasks into smaller ones
processed simultaneously.
o Data is often partitioned across several disks or processors to enhance speed
and efficiency.
 Advantages:
o Significantly improved performance for handling large datasets and complex
queries.
o Scalable, as additional processors or storage units can be added to improve
performance.
 Disadvantages:
o Complexity in setup and maintenance, as well as in handling data consistency
and synchronization.
o Requires specific hardware and software configurations, potentially increasing
costs.

d. Distributed Database

 Definition: A distributed database consists of multiple databases that are spread

across different physical locations, which may or may not be connected over a
network.
 Characteristics:
o Data is stored in multiple locations, but it appears as a single database to users.
o Can be categorized into homogeneous (all locations use the same DBMS) or
heterogeneous (different DBMSs at different locations).
 Advantages:
o Increased reliability and availability, as failure in one location does not bring
down the entire database.
o Can reduce network load by localizing data access to specific geographical
areas.
 Disadvantages:
o Increased complexity in data management, synchronization, and consistency
across locations.
o Higher setup and maintenance costs, as well as security challenges due to the
distributed nature.

Qn 6 a. Inner Join
An inner join returns only the rows where there is a match between both tables based on the
specified condition. If there is no match, the row is excluded from the results.

Example

Consider two tables:

Employees

EmployeeID Name DepartmentID

1 Alice 101

2 Bob 102

3 Charlie 103

4 David NULL

Departments

DepartmentID DepartmentName

101 HR

102 IT

103 Finance

104 Marketing

If we perform an inner join on Employees and Departments based on DepartmentID, the

result will include only the employees who have a matching DepartmentID in both tables.

SQL Query:

sql
Copy code
SELECT Employees.Name, Departments.DepartmentName
FROM Employees
INNER JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID;

Result:

Name DepartmentName

Alice HR
Name DepartmentName

Bob IT

Charlie Finance

David is excluded because there is no matching DepartmentID in the Departments table.

b. Outer Join

An outer join returns all the rows from one or both tables, even if there is no match. There
are three types of outer joins: left join, right join, and full join.

i. Left Join

A left join (or left outer join) returns all rows from the left table and the matching rows from
the right table. If there is no match, the result will include NULL values for the columns from
the right table.

SQL Query:

sql
Copy code
SELECT Employees.Name, Departments.DepartmentName
FROM Employees
LEFT JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID;

Result:

Name DepartmentName

Alice HR

Bob IT

Charlie Finance

David NULL

In this example, David is included even though he does not have a matching department in
the Departments table. The DepartmentName column shows NULL for him.
ii.Right Join

A right join (or right outer join) returns all rows from the right table and the matching rows
from the left table. If there is no match, the result will include NULL values for the columns
from the left table.

SQL Query:

sql

Copy code
SELECT Employees.Name, Departments.DepartmentName
FROM Employees
RIGHT JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID;

Result:

Name DepartmentName

Alice HR

Bob IT

Charlie Finance

NULL Marketing

Here, the Marketing department appears in the result, even though no employees are assigned
to it. The Name column shows NULL for this department.

iii. Full Join

A full join (or full outer join) returns all rows when there is a match in either table. Rows
without matches in either table will show NULL for the columns of the non-matching table.

SQL Query:

sql
Copy code
SELECT Employees.Name, Departments.DepartmentName
FROM Employees
FULL JOIN Departments ON Employees.DepartmentID = Departments.DepartmentID;

Result:

Name DepartmentName

Alice HR

Bob IT

Charlie Finance

David NULL

NULL Marketing

Both David and the Marketing department are included in the results. David has no
department, so DepartmentName is NULL for him, and no employee is assigned to
Marketing, so Name is NULL for the Marketing department.

c. Natural Join

A natural join automatically joins tables based on columns with the same names and
compatible data types in both tables. It doesn’t require specifying the join condition
explicitly, as it assumes the matching is based on columns with identical names.

Example

Given the same Employees and Departments tables, a natural join will automatically use the
DepartmentID column to join these tables, as it exists in both.

SQL Query:

sql
Copy code
SELECT Employees.Name, Departments.DepartmentName
FROM Employees
NATURAL JOIN Departments;

Result:

Name DepartmentName

Alice HR

Bob IT

Charlie Finance
Name DepartmentName

In this case, the result is the same as an inner join because DepartmentID is the only common
column name in both tables. David and the Marketing department are excluded because there
is no matching DepartmentID in one of the tables.

Qn 7. a. ER Model (Entity-Relationship Model)

 Definition: The ER model is a high-level conceptual model that visually represents

data and their relationships in a database. Developed by Peter Chen in the 1970s, it
focuses on identifying entities and their relationships.
 Components:
o Entities: Objects or concepts with distinct existence in the system, represented
by rectangles (e.g., Student, Course).
o Attributes: Characteristics or properties of entities, represented by ovals (e.g.,
Student’s Name, Course Code).
o Relationships: Associations between entities, represented by diamonds (e.g.,
Enrolled in).
 Advantages:
o Easy to understand and design, especially during the database design phase.
o Serves as a blueprint for building a relational database structure.
 Disadvantages:
o Limited to modeling static data structures; not ideal for capturing dynamic
aspects of data.
o Needs to be transformed into a relational schema for implementation in
RDBMSs.

b. Object-Oriented Model

 Definition: The object-oriented data model organizes data as objects, similar to

object-oriented programming concepts. Each object encapsulates data and behavior
(methods) in a single unit.
 Components:
o Objects: The basic units of data, containing attributes (data) and methods
(behavior).
o Classes: Templates or blueprints for creating objects, defining the properties
and methods.
o Inheritance: Allows new classes to inherit properties and methods from
existing classes, promoting reusability.
 o Encapsulation: Encapsulates data and methods together within objects,
promoting data security.
 Advantages:
o Better suited for complex data types, such as multimedia, CAD, and
engineering data.
o Supports inheritance, encapsulation, and polymorphism, enhancing reusability
and modularity.
 Disadvantages:
o More complex to implement and query compared to relational models.
o Limited adoption in traditional RDBMS environments due to its complexity
and non-standardized query language.

c. Network Model

 Definition: The network data model represents data as a collection of records

connected by links (pointers), forming a network-like structure. This model was
popularized by the CODASYL (Conference on Data Systems Languages) database
task group in the 1960s.
 Components:
o Records: Equivalent to entities in the ER model, storing data in a structured
format.
o Sets: Relationships or links between records, representing many-to-many
relationships.
o Pointers: Direct connections or links between records, creating complex
network structures.
 Advantages:
o Flexible and efficient for representing many-to-many relationships and
complex data interdependencies.
o Fast data access and retrieval due to direct pointers.
 Disadvantages:
o Difficult to modify or reorganize due to the complex structure and reliance on
pointers.
o Querying and updating data can be cumbersome, requiring extensive
knowledge of the data structure.

d. Hierarchical Model

 Definition: The hierarchical data model organizes data in a tree-like structure, where
each record has a single parent, and records are connected by parent-child
relationships. This model was widely used in early database systems such as IBM’s
IMS.
 Components:
o Nodes: Represent individual records in the hierarchy.
 o Parent-Child Relationships: Define the hierarchical structure; each child has
a single parent, but each parent can have multiple children.
o Root Node: The topmost record in the hierarchy from which all records
descend.
 Advantages:
o Efficient for representing and querying hierarchical data, such as
organizational structures or file systems.
o Simple to navigate as relationships are predefined.
 Disadvantages:
o Limited flexibility, as data relationships must conform to a strict hierarchy.
o Inefficient for many-to-many relationships, requiring redundant data or
complex workarounds to represent them.

Qn 8. A deadlock in a database system occurs when two or more transactions are waiting for
each other to release locks on resources, resulting in a cycle of dependencies where none of
the transactions can proceed. Deadlocks are problematic because they can halt progress in a
database, impacting performance and availability.

Example of How Deadlock Happens

Consider two transactions, T1 and T2, that both require access to two resources (data items A
and B) to complete their tasks. Here’s a scenario illustrating a deadlock:

1. Transaction T1 locks resource A and needs resource B to proceed.

2. Transaction T2 locks resource B and needs resource A to proceed.
3. Now, T1 is waiting for T2 to release resource B, while T2 is waiting for T1 to release
resource A.
4. Neither transaction can proceed, as each is waiting for the other to release a resource.
This circular dependency causes a deadlock.

Deadlock Detection and Prevention Techniques

To manage deadlocks, database systems use strategies for detecting and avoiding them. Here
are some commonly used techniques:

1. Deadlock Detection:
o Wait-for Graph: The system maintains a graph where transactions are nodes,
and an edge from T1 to T2 indicates that T1 is waiting for T2. The system
periodically checks this graph for cycles. If a cycle is found, a deadlock exists.
o Resolution: Once a deadlock is detected, the system may "rollback" (undo)
one of the transactions involved in the deadlock to break the cycle.

2. Deadlock Prevention:
 o Timeouts: Each transaction is assigned a timeout period. If it cannot obtain
the resources within this time, it’s assumed to be in a deadlock, and the
transaction is rolled back.
o Wait-Die and Wound-Wait Schemes:
 Wait-Die: Older transactions are allowed to wait if a resource is held
by a newer transaction. However, if a newer transaction requests a
resource held by an older transaction, it is rolled back.
 Wound-Wait: If an older transaction requests a resource held by a
younger transaction, the younger transaction is rolled back (wounded).
If a younger transaction requests a resource held by an older one, it is
allowed to wait.
o Resource Ordering: Establishing a consistent order for accessing resources.
Each transaction must request resources in a predefined order, eliminating
circular wait conditions.

3. Deadlock Avoidance:
o Banker’s Algorithm: Before granting a resource, the system checks if doing
so would lead to a potential deadlock. If granting the resource could cause a
deadlock, the request is denied, and the transaction waits until it can proceed
without causing a deadlock.

Each of these strategies has trade-offs. Deadlock detection is often simpler but reactive, while
prevention techniques proactively manage deadlocks, though they may introduce overhead.
The choice of technique depends on the specific requirements and performance
characteristics of the database system in use.

Qn 9. Concurrency control is a key concept in database systems that manages the

simultaneous execution of multiple transactions. Its primary goal is to ensure data integrity
and consistency while optimizing database performance in a multi-user environment.

Without concurrency control, transactions executed concurrently may interfere with each
other, leading to issues such as inconsistent data, lost updates, dirty reads, and phantom
reads. Concurrency control mechanisms prevent these issues, enabling reliable and correct
transaction execution.

Why Concurrency Control is Important

Concurrency control is necessary to handle problems that arise when multiple transactions
access the same data simultaneously. Here are common problems it addresses:

1. Lost Update: Two transactions read the same data and then update it simultaneously.
The changes made by one transaction can be overwritten by the other.
2. Dirty Read: A transaction reads data modified by another uncommitted transaction,
potentially reading data that may later be rolled back.
 3. Unrepeatable Read: A transaction reads the same data multiple times and gets
different results each time because another transaction modified the data in the
meantime.
4. Phantom Read: A transaction reads a set of rows that match a condition. Another
transaction then inserts or deletes rows that would have met that condition, changing
the result of the initial read.

Concurrency Control Techniques

To ensure that transactions do not interfere with each other, concurrency control relies on
several mechanisms and protocols:

1. Lock-Based Protocols
o Locks are used to control access to database items. Transactions must acquire
locks on data items before reading or writing.
o Types of Locks:
 Shared Lock (Read Lock): Allows multiple transactions to read a
data item simultaneously but prevents any of them from modifying it.
 Exclusive Lock (Write Lock): Allows only one transaction to both
read and write a data item, preventing other transactions from
accessing it.
o Two-Phase Locking (2PL): Enforces a rule where each transaction must
obtain all the locks it needs before releasing any. This protocol has two
phases:
 Growing Phase: The transaction acquires locks but does not release
any.
 Shrinking Phase: The transaction releases locks and cannot acquire
any new locks.
o Strict Two-Phase Locking: A more restrictive form where all locks are held
until the transaction commits or rolls back, ensuring serializability and
consistency.
2. Timestamp-Based Protocols
o Timestamp Ordering: Assigns a unique timestamp to each transaction and
uses this timestamp to manage access to data items. Transactions access data
in the order of their timestamps, with older transactions getting priority.
o Thomas’s Write Rule: An optimization in timestamp ordering that allows
certain writes to be ignored if they won’t affect the final outcome, enhancing
concurrency.
3. Optimistic Concurrency Control (OCC)
 o Optimistic Protocols assume that transactions will rarely conflict and let them
proceed without restrictions. Concurrency issues are checked only at the end,
during the commit phase.
o Phases in OCC:
 Read Phase: Transactions read and make changes in a temporary
space.
 Validation Phase: Checks if any conflicts occurred since the
transaction started.
 Write Phase: If no conflicts are detected, changes are applied to the
database; otherwise, the transaction rolls back.
o This is efficient in scenarios with low contention, as transactions don’t need to
wait for locks.
4. Multiversion Concurrency Control (MVCC)
o MVCC maintains multiple versions of data items to allow readers to access a
consistent snapshot of the data without being blocked by writers.
o Snapshot Isolation: Each transaction sees a “snapshot” of the database at the
time it started. This avoids many concurrency issues and is commonly used in
systems like PostgreSQL.
o MVCC is particularly useful in read-heavy environments, as it reduces locking
overhead.
5. Serialization and Serializability
o Serial Schedule: A schedule in which transactions are executed one after
another with no overlap.
o Serializable Schedule: A concurrent transaction schedule that produces the
same result as a serial schedule. Ensures data consistency by maintaining the
effect of transactions as if they were executed serially.
o Achieving serializability is a key objective of concurrency control and is often
enforced through locking or timestamp-based protocols.

Qn 10 Locking protocols are a fundamental part of concurrency control in database systems,

used to manage access to shared resources among multiple transactions. By regulating when
and how locks are applied and released, locking protocols prevent issues such as lost
updates, dirty reads, and inconsistent data that can arise from concurrent transaction
execution.

Types of Locks

1. Shared Lock (S Lock):

o Allows a transaction to read a data item but not modify it.
o Multiple transactions can hold a shared lock on the same data item
simultaneously.
2. Exclusive Lock (X Lock):
o Allows a transaction to read and modify a data item.
 o Only one transaction can hold an exclusive lock on a data item at any time,
preventing other transactions from accessing it simultaneously.

Common Locking Protocols

1. Two-Phase Locking (2PL) Protocol:

o Two-Phase Locking (2PL) is one of the most widely used locking protocols
to ensure serializability in transaction execution.
o The protocol divides the transaction’s execution into two phases:
 Growing Phase: The transaction acquires all the locks it needs but
does not release any locks.
 Shrinking Phase: Once the transaction releases a lock, it cannot
acquire any new locks.
o Strict 2PL: A variation of 2PL in which all locks are held until the transaction
commits or aborts, which prevents cascading rollbacks.
o Advantages:
 Guarantees serializability and prevents dirty reads and lost updates.
o Disadvantages:
 May lead to deadlocks, as transactions may hold locks while waiting
for other locks, leading to circular wait conditions.
2. Rigorous Two-Phase Locking:
o Similar to strict 2PL but even stricter, in which all locks are held until the
transaction is completely finished (either committed or aborted).
o This ensures the highest level of isolation, as no other transaction can access
any of the transaction’s locked resources until it is completed.
o This protocol is suitable for scenarios requiring strong consistency guarantees
but can reduce concurrency.
3. Timestamp-Based Locking Protocols:
o Transactions are assigned timestamps, and locking is managed based on these
timestamps to enforce serializability.
o Thomas’s Write Rule: A variant of timestamp-based locking, where a
transaction can ignore outdated writes if they do not affect the consistency of
the final output.
o Timestamp-based protocols often avoid the need for explicit locks and are
especially useful in high-concurrency environments.
4. Multiversion Concurrency Control (MVCC):
o MVCC allows multiple versions of a data item to be maintained, enabling read
operations to access an older version without waiting for write operations to
complete.
o When a transaction starts, it sees a “snapshot” of the database at a specific
point in time, isolating it from the changes of other concurrent transactions.
o Snapshot Isolation: A transaction reads from the version of data visible when
it started, which avoids read-write conflicts. However, write-write conflicts are
still managed by locking.
 o MVCC is popular in systems like PostgreSQL and Oracle for its efficiency in
read-heavy workloads.
5. Intention Locks:
o Intention locks are used to support hierarchical locking when there is a need
to lock a larger object (e.g., a table) while allowing finer-grained locks (e.g.,
rows) within it.
o Types of intention locks include:
 Intention Shared (IS): A transaction intends to acquire a shared lock
on some lower-level objects within a larger locked object.
 Intention Exclusive (IX): A transaction intends to acquire an
exclusive lock on some lower-level objects.
 Shared Intention Exclusive (SIX): A transaction holds a shared lock
on a higher-level object but intends to obtain exclusive locks on lower-
level objects.
o Intention locks help optimize locking in hierarchical data structures by
allowing transactions to lock only parts of a resource while still maintaining
overall consistency.
6. Dynamic Locking Protocols:
o In dynamic locking protocols, the level of locking (granularity) is adjusted
during the transaction’s execution based on its requirements.
o For example, a transaction may initially acquire a table-level lock but then
“downgrade” to row-level locks as it proceeds to minimize contention.
o These protocols are more flexible and can improve concurrency by reducing
lock contention but are complex to implement.

Avoiding Deadlocks in Locking Protocols

Deadlocks are a potential downside of locking protocols, especially in 2PL-based systems.

Several techniques are used to avoid deadlocks:

1. Deadlock Prevention:
o Use timeout policies to detect and resolve deadlocks by rolling back
transactions if they exceed a wait time.
o Implement Wait-Die or Wound-Wait schemes:
 Wait-Die: If an older transaction requests a lock held by a newer
transaction, the older transaction waits; if a newer transaction requests
a lock held by an older one, it’s rolled back.
 Wound-Wait: An older transaction requesting a lock preempts (or
“wounds”) a younger one, causing the younger transaction to roll back.
If a younger transaction requests a lock held by an older one, it waits.
2. Deadlock Detection:
o Use a wait-for graph to detect cycles (indicative of deadlocks) and break the
cycle by rolling back one of the involved transactions.
3. Resource Ordering:
o Define a consistent ordering for resource access, ensuring that transactions
request resources in a specific sequence, thereby reducing circular waits and
preventing deadlocks.