What is a collaborative application? General: an application - PDF document

What is a collaborative application? ◆ General: an application designed to assist Synchronization in people engaged in a common task Collaborative Applications – E-mail, video conferencing, database system, shared editor, the Web ◆ Specifically interested in collaborative Jonathan Munson applications that involve shared data University of North Carolina at – database system, shared editor, the Web Chapel Hill What is synchronization? Synchronization ◆ Synchronization controls access to shared ◆ Prevents users from editing same object data to prevent users from interfering with simultaneously each other. ◆ To illustrate, some scenarios involving User A User B collaborative applications Alternative policy: exclusive Planner—exclusive editing policy editing ◆ For safety, as plans ◆ Users can specify that certain drawings get finalized, a user cannot be modified concurrently, as a may wish to get matter of policy. exclusive access to an entire drawing

Alternative application: Group discussion tool room scheduler ◆ Synchronization should disallow concurrent insertions of reservations that conflict. 9:00 am delete 9:30 am Budget meeting A’s comment ? 10:00 am ☛ 10:30 am Weekly review B’s reply B’s reply 11:00 am insert Implications: (1) programmer- defined consistency criteria Synchronization model ➊ Users submit operations in transactions ◆ Notions of conflict vary from application to application User 1 User 2 – In drawing application, users can always insert (BeginTransaction Operation* EndTransaction)* objects concurrently – In room scheduler, only non-conflicting inserts Synchronization logic are allowed. ➋ Operations are Schedules Shared validated w.r.t. (interleaved transactions) data concurrent operations Synchronization systems Consistency requirements & criteria ◆ Provide synchronization on behalf of applications ◆ Consistency requirements: User 1 User 2 – specify the set of ideally allowable schedules. – “Users may concurrently add room reservations Application Consistency requirements (that don’t overlap), but may not concurrently change the same reservation.” Synchronization system Consistency criteria ◆ Consistency criteria: – specify the set of actually allowed schedules. Shared – “Users must access the set of reservations one data at a time.”

Optimal synchronization Traditional criteria: serializability ◆ The synchronization system’s consistency criteria ◆ Concurrent transactions execute as if they were match the application’s consistency requirements. submitted one after the other. consistency requirements all possible all possible schedules consistency schedules serializable criteria schedules Programmer-specified criteria User-specified consistency criteria ◆ Programmers should be able to specify the ◆ Users cannot use low- ◆ …but can use high- consistency criteria used for their application level mechansisms level mechanisms (code, predicates) (tables, buttons) Consistency criteria int IsCompatibleLockToLock(lock_requested, lock_held) Dictionary Put Remove Modify Null for application X LockType* lock_requested; LockType* lock_held; { Put Column Row Column Row char* lock_table; int row_index, col_index, num_cols; Remove Column Same Column Row /* check if owned by self */ if (!strcmp(lock_requested->owner, lock_held->owner)) return 1; switch (lock_requested->kind) Modify Column Row Merge Row { case symtab_kind_record: lock_table = record_lock_table; Null Column Column Column row_index = lock_requested->mode; serializable num_cols = NUMRECORDLOCKS; break; case symtab_kind_sequence: lock_table = sequence_lock_table; schedules Consistency if (lock_requested->index == lock_held->index) row_index = lock_requested->mode; else (transactions row_index = lock_requested->mode + 4; criteria for num_cols = NUMSEQUENCELOCKS; break; default: execute as if lock_table = generic_lock_table; application Y row_index = lock_requested->mode; num_cols = NUMGENERICLOCKS; } one after the col_index = lock_held->mode; return lock_table[row_index*num_cols + col_index] == ’Y’; } other) Mobile collaboration: cure in Implications: (2) late and early addition to prevention validation ◆ Users may not be at all times connected. ◆ All users may be connected Some may travel and modify the drawings ◆ All users may be disconnected (mobile) when disconnected. ◆ Mixed Client Client Server Client Client

Early validation Late validation ◆ Operations are ◆ Operations are ET Op ET Op validated w.r.t. validated w.r.t. concurrent operations concurrent operations C Validation T at time of submission at commit time T ◆ Examples: locking, ◆ Examples: optimistic multiversion concurrency control, C timestamp ordering copy-modify-merge Validation software development Update Update Early validation vs. late validation Early validation vs. late validation Early validation Late validation Early validation Late validation L Per-operation J No per-operation L Per-operation J No per-operation overhead overhead overhead overhead J Conflict blocks only L Conflict may cause single operation loss of all operations Early validation vs. late validation Early validation vs. late validation Early validation Late validation Early validation Late validation L Per-operation J No per-operation L Per-operation J No per-operation overhead overhead overhead overhead J Conflict blocks only L Conflict may cause J Conflict blocks only L Conflict may cause single operation loss of all operations single operation loss of all operations K For tight coupling, K For parallel develop- K For tight coupling, K For parallel develop- with safety ment of alternatives with safety ment of alternatives L Not functional if J Functional when network is down disconnected

Conclusion: need flexibility! A simple solution to flexibility: ◆ Programmer-specified consistency criteria ◆ Programmers write the synchronization code themselves ◆ Early and late validation – Rover (late validation) ◆ And many others... – Prospero (early validation) Our goal: a balance Incremental Specification ◆ Support varying levels of “synchronization awareness” in applications Our goal – no awareness: inherit default policies Flexibility – medium-level awareness: specify policy – high-level: implement policy Existing ◆ Awareness can be incrementally increased systems ◆ Constraint: Co-exist with existing Ease of specification infrastructure Incremental Specification Scenarios and requirements ◆ Policy ➨ Merge- and locking- ◆ Requirements varied ➨ Programmer- from application to specified inheritance aware types application consistency criteria ◆ Policy ➨ Merge matrices and ◆ Users added their own ➨ User-specified specification lock tables requirements consistency criteria ◆ Policy ➨ Subclassing, new ◆ Groups included both ➨ Early and late implementation types connected and validation disconnected users ◆ Specification was ➨ Incremental incremental Specification

Co-existing with Existing Three aspects of solution Infrastructure ☛ ◆ Merging ◆ Suite Collaboration System Suite Merge Tool – Sharing of C Types ◆ Locking – Assumes Connected Operation ◆ Integration (coexistence) – Provides and Assumes C-based User- Interface Generator ◆ Java + “MVC” Sync Suite Merge Tool Sync framework ◆ Uses asynchronous merging to serve disconnected, mobile users – Users work without coupling between their views, and then synchronize before committing ◆ No predefined user interface, so may extend – Interactive selection of alternatives to applications with arbitrary user interfaces – Merge policy selected at merge time, by users ◆ Basis in object-oriented programming language (Java), more extendible than Suite’s C basis—method overriding, user- defined abstract data types ◆ Fully automated merging. Synchronous Vs Asynchronous Merging Connected Merging in Suite ◆ Assumes connected system ◆ Users must “meet” to merge Synchronous Asynchronous User interface User interface A 1 , B 1 , A 1 , B 1 , Suite Suite C 1 C 1 Dialogue Merge Dialogue A 2 B 2 A 2 B 2 Manager Manager Merge Merge A 3 , B 3 , B 2 , C 2 Application C 2 Merge Object A 3 , C 3