Improving availability by consistency negotiation in an objectbased distributed system

1
Improving availability by consistency
negotiation in an object-based distributed system

• (Lorenz Froihofer, Vienna University of
  Technology)

2
Outline

• Motivation and introduction
• Overview and classifications of object-based
  integrity constraints
• Consistency threats and negotiation
• Future work

3
Motivation

• Distributed systems have to be highly available
  (7x24).
• With an increasing number of nodes and links,
  failures become more probable.
• If a system requires full consistency all the
  time (e.g. banking applications), the system
  becomes unavailable during failures.
• For some systems (e.g. safety critical
  applications), availability is more important
  than full consistency.

4
Trade-off consistency - availability

• If a system can relax consistency during degraded
  mode (e.g. node or link failure), we use the
  following model

5
Network partition

• Network partitions are caused by link failures
• Communication between computers in different
  network partitions is not possible

6
System model and consistency threats
7
Consistency types

• Constraint consistency is defined via data
  integrity constraints (? Focus for the trade-off
  consistency vs. availability).
• Concurrency consistency (isolation) takes care of
  the concurrent access to local data items.
• Replica consistency maintains the consistency of
  replicated data items.

8
Transaction properties

• Transactions are defined by the ACID properties.
• Healthy system Replica control operates on top
  of ACID transactions.
• Degraded system Constraint consistency control
  and replica control operate on top of AID
  transactions.

9
Main ideas and contribution

• Fine-grained trade-off between availability and
  consistency
• Classification of object-based integrity
  constraints with respect to the trade-off
• Runtime-separation of constraints from business
  logic, no hard-wired constraints in the best case
• Identification and negotiation of consistency
  threats
• Design of a system model that integrates these
  aspects
• Proof of concept

10
Object-based integrity constraints

• Data integrity constraints defined upon objects
• Constrain the values of attributes and the
  possible references between objects.
• Two main classes with respect to the trade-off
• Intra-object constraints (e.g. value of a single
  object)
• Inter-object constraints (e.g. cardinality of an
  association)

11
Design view vs. runtime implementation

• Design time separation of constraints and
  business logic is the usual case.
• For runtime implementation, constraint checking
  code is tangled with all other code.
• To be able to trade constraint consistency, the
  constraints have to be explicitly available at
  runtime.
• The goal is to keep constraints as separate from
  the business logic as possible even at runtime.

12
Towards explicit runtime constraints

• Advantages
• Ensuring that constraints are implemented in a
  system becomes easier controllable.
• Decoupling of constraints from business logic
  allows quicker and more flexible adaptation to
  changing consistency requirements (runtime
  management of constraints!).
• Disadvantages
• Decoupling of constraints causes a performance
  loss compared to simple if then statements.

13
Constraint checking affected by availability

• Full constraint check (FCC) Objects are
  up-to-date
• Limited constraint check (LCC) Objects are
  possibly stale
• No constraint check (NCC) Objects are not
  available
• ? A constraint can have one of the following
  satisfaction degrees
• Satisfied FCC satisfied
• Possibly satisfied LCC satisfied
• Possibly violated LCC violated
• Uncheckable NCC
• Violated FCC violated

14
Negotiation of consistency threats

• Operations that threaten non-tradeable
  constraints cannot be performed.
• If all constraints are non-tradeable, the system
  falls back to a strict/full consistency model.

Integrity constraints
tradeable
non-tradeable
static trade-off decision
dynamic trade-off decision
15
Static vs. dynamic negotiation decisions

• Static negotiation decisions
• Minimum satisfaction degree per constraint
• Optional staleness criteria for the estimated age
  of an object.
• Specified during design or deployment time
• Dynamic (programmatic) negotiation decisions
• Implementation of a negotiation handler
• Negotiation handler is called for consistency
  threats during runtime

16
Dynamic negotation example
17
Reconciliation hints

• Generated during negotiation of consistency
  threats
• Specify how potential constraint violations are
  solved at reconciliation time
• Roll-back vs. roll-forward strategies
• Enable different reconciliation strategy per
  consistency threat

18
Decoupling of constraints and negotiation from
business logic

• Keep constraint enforcement and negotiation of
  consistency threats a completely separate aspect
  of a system.
• Programmer should not have to consider
  constraints and consistency threats while
  implementing the core business logic.
• Specification of constraints and trade-off
  decisions should be sufficient other
  functionality, e.g. the triggering of constraint
  validation, should be implemented by the
  middleware.

19
Trade-off simulation studies

• Based on a simplified model of the trade-off and
  the replication protocols
• Investigated different combinations of various
  parameters such as the duration of a network
  partition, invocation of a negotiation handler
  and others.
• Showed that system availability can benefit from
  the trade-off if the system stays in degraded
  mode (network partitions, node failure) for a
  long while.

20
Future work

• Development of an appropriate system model
• Specification of a well defined interface between
  the replication protocols and the consistency
  negotiation layer
• Proof of concept implementation with EJB
• Writing the thesis ?

21
Its time for your questions!

• What/how do you think about explicit runtime
  constraints?
• How could you benefit from explicit runtime
  constraints?
• How do you think software engineering will
  benefit from explicit constraints?
• Are you working in a similar area, considering
  similar topics?
• What do you think about the negotiation of
  consistency threats?
• Is the presented model sound? Is it clear to you?