GROUP 8 MEMBERS: 31ST JULY 2025.

1. Ruth Ngigi – 674478

2. Cosmas Kiprotich – 674470

CHAPTER 6: TRANSACTION PROCESSING.

a) What are the key challenges in managing transactions in distributed database systems
(DDBS)?
 Access Control and Transaction Management: DDBS require different
mechanisms for monitoring data retrieval and updates across distributed and
replicated databases. While centralized systems also handle concurrent user access
and deadlock resolution, DDBS add layers of complexity due to data distribution.
 Complexity and Cost: DDBS are inherently more complex and costly to implement
and maintain, requiring more hardware, software, and specialized technical expertise
at each site.
 Data Replication and Retrieval Transparency: The system must ensure that data
replication and retrieval from various sites are completely transparent to the user,
which adds to the system's design and operational complexity.
 Security Issues: Managing security across geographically dispersed locations is
more challenging, and communication links between sites can be vulnerable to
unauthorized access.
 Failure Management: i.e
 Site Failures: Hardware or software crashes at one or more sites can interrupt
ongoing distributed transactions and lead to the loss of main memory
contents.
 Network Communication Failures: Packet loss, delays, or disruptions in the
network can lead to inconsistent transaction states or network partitioning,
where sites become isolated.
 Transaction Failures: A transaction may abort maybe due to deadlocks or
concurrency control issues, requiring the database to revert to its state before
the transaction began.
 Media Failures: Secondary storage device failures i.e hard drive crashes can
make parts or all of the database inaccessible.
 Concurrency Control: Ensuring isolation across multiple sites is complex and may
lead to deadlocks.
 Atomicity Across Sites: Achieving all-or-nothing execution is difficult when
different sites may have different states.
 Data Consistency: Replication and partitioning require careful synchronization to
maintain consistency.
 Recovery After Failures: Coordinating rollback or commit after site or network
failures is difficult.
 Commit Coordination: Requires global agreement, which is time- and resource-
intensive.

b) Design a simple flowchart to represent the Two-Phase Commit process in Oracle.

 START

Global Coordinator Initiates Transaction

Assigns roles: Commit Point, Local Coordinators

Global Coordinator sends PREPARE to all nodes except Commit Point

Nodes respond with either:

Prepared or
Read-only or Abort
Coordinator checks responses: If any Abort or Not prepared

GLOBAL ABORT
If all Prepared

instruct Commit Point to COMMIT

Commit Point Commits Locally

Commit Point Site Informs Global Coordinator of Commit

Coordinator sends COMMIT to all nodes

All nodes commit and log → All Transactions Committed

(Forget Phase) global coordinator instructs the commit point site to "forget" the transaction

Commit Point Site "Forgets" Transaction and Informs Global Coordinator

Global Coordinator "Forgets" Transaction

Transaction Committed Successfully

END
c) Discuss the implications of partial site failure versus total system failure in a distributed
transaction.
Partial Site Failure- Only some nodes or communication links within the distributed system
fail, while others remain operational
 Blocking, if a node fails while in the PREPARED state, it holds locks on data
without knowing whether to commit or abort. where other transactions needing
access to that locked data are indefinitely delayed, causing deadlocks and forcing
other transactions to abort.
 Network partitioning (due to communication failures) is a form of partial failure that
can lead to inconsistent states, as isolated groups of sites might proceed
independently.
 Resource locking and performance degradation can also occur.
Total System Failure- All sites within the distributed database system fail simultaneously
 Causes complete system downtime, but can sometimes be simpler to recover from
in terms of transaction consistency.
 All transactions halt. The system typically performs a "crash recovery," rolling back
all uncommitted transactions to the last consistent state.
 The system may require a global recovery procedure. If commit logs are intact,
committed transactions can be recovered; otherwise, data loss may occur. Relies
heavily on robust logging and recovery mechanisms.
d) What are the limitations of the Two-Phase Commit protocol, particularly in terms of
blocking and recovery?
 Coordinator Failure: If the coordinator fails after participants have voted
PREPARED but before sending the global commit/abort decision, the participants
remain in the PREPARED state indefinitely, holding locks on resources. They
cannot unilaterally decide to commit or abort without violating atomicity, thus
blocking other transactions that require those resources. Participants must wait for
coordinator recovery to proceed.
 Participant Failure: If a participant fail after sending its "Prepared" vote but before
receiving the final decision, it will remain blocked upon recovery until it can re-
establish contact with the coordinator.
 Communication Failures: Network disconnections can also cause blocking, as
nodes cannot communicate to finalize the transaction.
 Recovery Complexity: Recovering from failures within the 2PC protocol can be
complex, requiring careful coordination and examination of transaction logs to
determine the state of transactions and ensure consistency.
 High Latency/Message Traffic: 2PC involves multiple rounds of message
exchanges (prepare requests, votes, commit/abort commands, acknowledgments),
which can introduce significant network latency and increase commit time,
especially in large, geographically distributed systems.
 Synchronous Nature: The protocol is synchronous; the coordinator must wait for
all votes before deciding, and participants must wait for the global decision. This
sequential dependency can create performance bottlenecks.
  Single Point of Failure (Coordinator): The centralized coordinator is a critical
component. Its failure can halt the progress of all distributed transactions it manages,
leading to the blocking issues described above.
 Resource Locking: Locks must be held until the commit decision is known.
 No Built-in Consensus: The protocol doesn't inherently tolerate conflicting
decisions from nodes.
e) Propose enhancements to Oracle’s 2PC protocol to reduce latency or improve fault
tolerance in high-availability systems.
1. Optimistic Two-Phase Commit:
 The coordinator proactively sends the commit message immediately after the prepare
message, assuming all participants will vote "yes." Only if a participant explicitly votes
"no" is an abort initiated.
 Reduces a round-trip delay in the common successful commit path, significantly
lowering latency but requires robust rollback mechanisms for the rare cases where a
participant cannot commit.
2. Decentralized/Distributed 2PC:
 The coordinator sends a prepare message, and then each participant broadcasts its vote
to all other participants. Each node decides to commit or abort once it has received all
votes.
 Benefit: Eliminates the single point of failure of a centralized coordinator and can reduce
decision-making latency by allowing parallel vote processing and independent decision-
making at each node.
3. Asynchronous Forget Phase with Advanced Queuing (AQ):
 Makes the final cleanup asynchronous, in return freeing up resources and reduces the
synchronous overhead of the coordinator and commit point site faster, improving
throughput without compromising atomicity.
4. Lease-Based Resource Management:
 Implement a lease system for locked resources. If a coordinator or participant fails and
doesn't renew its lease within a defined timeout, other nodes can assume a failure and
potentially release locks or abort the transaction after a safe period. Limits the duration
of blocking caused by failures.
5. Coordinator Replication/High Availability:
 Implement a hot standby or primary-standby architecture for the global coordinator. If
the primary coordinator fails, a replica can seamlessly take over its role and resume
coordinating transactions. Eliminates the single point of failure, drastically reducing
downtime and blocking.
6. Optimized Read-Only Transactions:
 Bypass full 2PC for read-only nodes to reduce unnecessary message exchanges and
coordination overhead for read-heavy distributed queries.
7. Three-Phase Commit (3PC) Protocol:
 Adds a "Pre-Commit" phase between the Prepare and Commit phases to avoid blocking
by allowing participants to make autonomous decisions if the coordinator crashes.
8. Decentralized Logging:
 Concept: Store transaction logs on multiple nodes rather than a single point to support
faster recovery and better resilience.
 CHAPTE 8: DATABASE ARCHITECTURE

a. With the aid of a well labeled diagram, illustrate the key architectural differences between
thin client and fat client systems.
A thin client is a computer that mostly connects to applications and resources on a remote server
instead of using its own processing power and storage.
A thick client is a type of software that does a lot of its processing on the user's own device (the
"client") instead of relying heavily on a remote server.

 Thin Client  Thick Client

 - Most processing (application logic, business  - Processing like application logic, user
logic, and data storage) happens on the server. interface, and some data storage happens on the
 - The client mainly handles the user interface and client side (user’s computer).
sends input to the server.  - The server mainly handles data storage
 - Highly dependent on network connectivity; the (database) and sometimes business logic.
client needs a constant connection to the server.  - Can function with limited network
 - An example of thins client is Web-based connectivity since much of the application runs
applications, Virtual Desktop Infrastructure locally.
(VDI), remote desktop solutions.  - Example of Thick client is like Desktop
applications like Microsoft Outlook, Adobe
Photoshop.
b. The paper argues that thin client acceptance is more about integration strategy than
technical capability. What architectural decisions support this claim?
 Thin clients work best in companies that strategically align their IT processes with
centralized control and management.
 Having a strong and reliable network infrastructure is also very important for the
successful use of thin clients.
 A scalable system design that takes into account future growth makes thin client
deployments more likely to last a long time.
 Thin clients are easier to accept when they are part of a larger security strategy that
benefits from having all the controls in one place.
 Making sure that applications work with thin client systems is an important part of
integrating them.
 To get people to use it widely, you need to meet their needs for user experience, like
supporting peripherals and keeping sessions stable.

c. What database-level security considerations arise in thin client deployments?

 Centralized Data Access means that only the application server can talk to the database
and direct access to the database is not allowed.
 Authentication and authorization are done by making sure that users and applications that
access the database have strong authentication.
 Encryption—data that is being sent between the thin client, application server, and
database should be encrypted. Data that is not being used should also be encrypted to keep
it safe from breaches.
 Auditing and Monitoring: This is done by turning on database logging and auditing, which
keeps track of who accesses the database and what changes they make, and sends reports
on any strange or unauthorized activity.
 Give database users and applications only the permissions they need.
 Backup Security: Encrypt and control access to your database backups, and keep them in a
safe place.

d. The paper uses login events and reservation data to assess usage. What additional database
metrics could be used to evaluate system performance and user engagement?
System Performance Metrics
 Average time for database queries to run shows the Query Response Time.
 Transaction Throughput is based on how many successful transactions happen in a
second.
 Lock contention is measured by how often database locks slow down performance.
 Connection Latency is measured by Time taken to establish a database connection
User Engagement Metrics
 The length of time users remain active during a session determines the session
duration.
 Utilization Frequency by determining which database-driven features are most
frequently used.
 Failed Login Attempts used to indicate potential security risks or UX issues.
e. How might thin client architectures be adapted for resource-constrained educational environments
in LMICs?
 Use of inexpensive thin clients, such as Chromebooks, Raspberry Pis, or old PCs that
have been repurposed or refurbished.
 Devices with no local storage, or zero clients, save money on maintenance.
 Energy Efficiency: Use thin, low-power clients to cut down on electricity expenses. In
off-grid locations, use solar-powered servers.
 Server Consolidation: Through virtualization, a single mid-range server can
accommodate several thin clients.
 Reduce licensing costs by using lightweight operating systems and applications, such
as Linux-based thin clients (LTSP, Ubuntu Edge).
 Preload textbooks, videos, and quizzes in compressed formats to introduce localized
and low-bandwidth content.
 Training and Local Technical Support by giving teachers and local technicians basic
IT training, routine troubleshooting is made possible and reliance on outside assistance
is decreased, promoting long-term sustainability.