Semantic Concurrency Control for RealTime Diagramming

1
SemanticConcurrency Control for Real-Time
Diagramming

• Group 99 Workshop
• Jeffrey Campbell
• University of Pittsburgh
• jeffc_at_sis.pitt.edu

2
Introduction

• Diagrams
• Background
• Current Work

3
Diagrams of Interest

• Focus of activity, final product (deliverable)
• Object oriented graphics
• Synchronous usage
• Multi-object actions
• Domain constraints on correctness

4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
Background

• Database Concurrency Control
• CSCW Control Approaches
• Problems

8
Concurrency Control

• DBMS Concurrency Control Mechanism
• Supports multiple simultaneous transactions
• Isolates transactions from each other
• Maintains database consistency

9
Transactions

• Transaction
• Logical Unit of Work
• ACID Properties
• Atomic All or nothing
• Consistent DB correct before and after
• Isolated No interference between trans
• Durable Protected from system failure

10
Transactions

• Correctness
• Serializability
• Semantic
• Two Phase Locking
• Holds locked resources to end of transaction

11
Extended Transactions

• Many Approaches (Elmagarmid, 1992)
• Split Transactions (Kaiser)
• Release resources before end of transaction
• Serializability correctness criterion
• If resources are used by others, transaction may
  have to be aborted if later action aborts

12
Collaborative DiagrammingLocking Problems

• Difficult to identify beginning and end of
  transactions
• Actions take a long time, blocking items for a
  long time
• Focus is on transaction identification

13
Transaction Identification Semantic Approach

• Identify logical units of work in diagrams
• Domain constraints define such units
• Diagram correctness is preserved
• partial / incorrect diagrams may be saved
• transaction re-starts when diagram re-opened

14
Long Transactions

• User action blocked for long time
• 2PL holds locks until end of transaction
• Possible Improvements
• Reduce length of transaction
• Allow users to work by blocking access, not all
  other work
• Release locks before end of transaction

15
Long TransactionReduce Length

• Better transaction identification results in
  shorter transactions than the work session
• Does not require separate user action to indicate
  transaction begin or end point

16
Long TransactionAction Not Blocked

• DB transaction requesting locked item waits for
  that item
• CSCW users can
• Work on something else
• Wait for release of item needed
• Request the item from another user

17
Long TransactionRelease Locks

• Tickle locks (Greif, et al)
• Release if requested and inactive
• Split Transaction (Kaiser)
• Divide transaction into two transactions
• Release resources before end of transaction
• Serializability correctness criterion
• If resources are read by others, they will have
  to be aborted if source transaction aborts

18
Long TransactionsEnhanced Split Transactions

• Domain criteria define correctness
• Any diagramming transaction may be split
• Users control request and granting of split

19
Current Work

• CoDiagram System
• Usability Evaluation

20
CoDiagram

• Collaboration Transparent user interface (Visio)
  with central server
• Implementation lessons
• Difficult to divide graphic event stream into
  user actions
• Local versus remote origin
• Redundant events for multi-shape actions
• Sequence issues for local undo

21
CoDiagram

• Supports several locking approaches
• Adjustable awareness features
• Varied levels of syntax support

22
Usability Evaluation

• How groups develop diagrams
• Types of conflicting actions
• Frequency of conflicts with no system controls
• Currently in progress

23
Summary

• Domain constraints define transactions that
  support automatic acquisition and release of
  locks
• Locks may be transferred between people by
  implementing split transactions
• Not a complete solution for all applications, but
  another technique to use where appropriate