This document discusses key factors of real-time distributed database systems. It defines hard and soft real-time systems and explains how concurrency control is more challenging in a distributed real-time environment. Both pessimistic and optimistic concurrency control approaches are covered. Replication strategies are also discussed, including full replication with eager vs lazy updating, and primary vs update-anywhere models. Partial replication is presented as an alternative to reduce overhead. The conclusion emphasizes that replication strategies must adapt to real-time constraints.

1. Real-Time Distributed Databases

2. Goals
• Real-Time Distributed Database Systems a
relatively new area of research.
• Increase Understanding of Real-Time
Distributed Database Systems.
• Present information about key factors of
Real-Time Distributed Databases.

3. Topics
• Hard vs. Soft RTDDBS
• Concurrency Control in RTDDBS
• QoS and QoD through Replication

4. Databases
• Database:
– A collection of related data with meaning
• Distributed Databases:
– A database that consists of two or more data
files located at different sites on a computer
network.

5. Real-Time Distributed Databases
Distributed Databases with the added
constraint of completing operations within a
certain amount of time to accurately reflect
the outside world.

6. Real-Time Distributed Databases
• Strategies must suit system attributes
– Hard or Soft
– Concurrency Control
– Replication

7. Hard vs. Soft
Hard
• Strict timing constraints
• Data and Service
guaranteed
• Deadlines met to avoid
catastrophe
• Example:
– Control tower notifying
planes where to land in
inclement weather
– Burglary System dispatch
Soft
• Less strict timing
constraints
• Failure to meet deadlines
not dangerous
• Value of data declines
after deadline.
– Example: Checkout line
growing in a grocery store.

8. Concurrency Control
• Ensures data is accurate even in a
distributed system
• Two main approaches:
– Prevent Collisions (Pessimistic)
– Detect Collisions and Respond (Optimistic)

9. Pessimistic Concurrency Control
• Two-Phase Locking:
– Transactions acquire locks on data
– After transaction completed, locks are
removed.
– Ensures that data integrity isn’t compromised.

10. Pessimistic Concurrency Control
• Disadvantages to 2PL:
– Don’t scale well to distributed systems
– Difficult to maintain locks at different locations
– Problems inherent to locking multiplied by
number of sites

11. Optimistic Concurrency Control
• OCC:
– Assumed that collisions won’t occur
– Few or no read restrictions
– Initial writing takes place on copy of data
– Course of action can be decided based on
collision

12. Optimistic Concurrency Control
• Disadvantages to OCC:
– The less servers, the more likely collisions
– Collisions always cause rollbacks
– Time wasted while restarting transactions

13. Variations on CC
• Neither OCC nor PCC perfect for RTDDBS
• Variations/Augmentations frequent:
– DHP-2PL
– OCC Wait-50

14. Replication Strategies in Real-Time
Distributed Databases
Replication
• Deadlines must be met
• Fault tolerance
• Failure Transparency
• Replication helps maintain Quality of
Service and Data Freshness

15. Full Replication
• All data replicated at multiple sites
– High fault tolerance
– Failure transparency
– Improved response times through querying
local data

16. Full Replication
Two Categories:
– When replication takes place
• Eager or Lazy Replication
– Where the replication takes place
• Primary or Update-Anywhere

17. Full Replication:
Eager vs. Lazy Update
Eager Update
• Replicas updated as
transaction happens.
• High response times
from clients.
• Locked longer.
• High Overhead
Lazy Update
• Replicas updated
after transaction
committed.
• Chance for
inconsistency.

18. Full Replication:
Update Anywhere vs. Primary Copy
Update Anywhere
• Any replica can
update other replicas.
• Good for fault
tolerance.
• High synching and
update times.
Primary Copy
• One replica
designated as
“server”.
• Good for read-only
transactions.
• Restarts at server
mean long waits and
missed deadlines.

19. Alternative: Partial Replication
• JITRTR: Replicate as needed.
• Only parts of the database replicated to
cut down on overhead.
• Works best in static systems

20. Conclusion
• Replication strategies must adapt to Real-
Time systems.
• Variations or Augmenting traditional
algorithms necessary.
• Every RTDDB system has different
requirements.
• No single excellent implementation for all
systems.