Optional and responsive locking in collaborative graphics editing systems By School of Computing and Information Technology Griffith University Brisbane, Queensland 4111 Australia David Chen Chengzheng Sun

Outline Object graphics collaborative editing systems Locking The GRACE system Locking in GRACE –Responsive operation generation –Intention preservation –Lock ownership Conclusion

Real-time object graphics collaborative editing systems These systems allow multiple users to edit the same document at the same time from different sites. An object graphics document is a collection of one or more graphical objects such as line, rectangle and circle, etc. A graphical object consists of attributes, such as type, position, size and color etc. Editing operations, such as create, move and fill etc, are used to modify the document. What is the use for locking?

Locking in existing systems First used to maintain consistency in database systems. It is also used to maintain consistency in many object graphics collaborative editing systems, e.g. Ensemble, GroupDraw, GroupGraphics and GroupKit. How does locking work: Before an operation can be generated to edit an object, a lock on that object has to be obtained. Locking prevents the generation of concurrent operations on the same object. Locking is compulsory. Disadvantages of locking: Pessimistic locking slows down the response time. Optimistic locking does not preserve the generation effects of all operations. The system decides which effect the users would see based on unrelated information.

The GRACE system GRACE (GRAphics Collaborative Editing) system. GRACE has a distributed replicated architecture. Each site maintains a copy of the shared document. When an operation is generated it is first applied to the local copy, then sent to all remote sites. The intention preservation property of GRACE ensures the generation effects of all operations are preserved. Object replication is used to maintain intention preservation.

The dependency relations are defined based on Lamport’s happen before relation: O b is dependent on O a, iff O a happened before O b denoted by O a  O b. E.g: OaOa ObOb O a and O b are independent, iff neither O a  O b, nor O b  O a, denoted by O a || O b  E.g: OaOa ObOb OaOa ObOb OcOc OaOa ObOb Intention of an operation The intention of an operation O is the editing effect which can be achieved by applying O on the document state from which O was generated. Intention preservation property For any operation O, the effects of executing O at all sites are the same as the intention of O, and the effect of executing O does not change the effects of independent operations.

Object replication scheme Definitions: Independent operations targeting the same object and changing the same attribute to different values are called conflicting operations. Operations not conflicting are compatible. Replication effect: For two conflicting operations O a and O b, targeting object G, replicates of G, G a and G b are made for the application of O a and O b respectively. For two independent compatible operations O a and O b targeting the same object, there must be at least one object/replica, which contains the effects of both O a and O b. Move left Move right replica

Locking in GRACE The role of locking in GRACE: Locking is used to reduce the generation of conflicting operations which cause object replication. Locking is not used to preserve intentions of operations, therefore, locking an object before applying operations is optional. What can be locked? Graphical objects. Regions. –A region is an area in the drawing space. –Locking a region can be used to obtain a private working space. A lockable item is either an object or a region. A locking operation specifies either one or more objects or a region to be locked.

What does a user get for locking an item? If a user locks an object G then the system guarantees s/he the editing right to G. If a user locks a region R then the system guarantees s/he the editing right to R and all objects within R. What if the user did not lock an item before editing? That user’s editing request will be rejected iff that item is locked by someone else.

Responsive operation generation How locking operations can be generated: Implicitly - generated by the system. Explicitly - generated by the users. With the introduction of locking, user generated editing/locking requests need to be validated. A user’s request is valid if the target item on the local document is unlocked or s/he owns the lock. Otherwise it is invalid, and is rejected right away and the user informed. This validation process relies only on the current local document state, therefore fast response time is ensured. For any each valid request, an operation is generated. User request Local validation Operation generation Local execution Remote execution Rejection

Intention Preservation Locking introduces new intention preservation problems: How to preserve the intention of an editing operation which targets an object locked by an independent locking operation? How to preserve the intentions of independent locking operations targeting the same object? Solution: allow these independent operations to be applied to the same object. Move(G)Lock(G) An unstable period of a lock is used to inform lock owners that the locked item may be edited or locked other by independent operations. An unstable period of a lock generated by locking operation L, is the period starting when L is applied on the item until all operations independent of L targeting that item have been applied.

If there are two or more independent locking operations targeting the same item, then all users who generated these locking operations will own the lock on that item. This item is locked by a shared lock. All owners of an item locked by shared lock can edit that item. After the unsafe period, if only one user owns the lock, then that user will have exclusive access to that item. This item is locked by an exclusive lock. After the unstable period, only the lock owner(s) can editing that item. Notations: Let Owner(I) denotes the a set of users who owns the lock on item I. Let |Owner(I)| denotes the number of users who owns the lock on I. A lock on an item I is exclusive if |Owner(I)| = 1. A lock on an item I is shared if |Owner(I)| > 1.

Shared lock ownership What should be the lock ownership for independent locking operations those target item is the same or overlaps? Let L 1 and L 2 be two independent locking operations generated by users U 1 and U 2. If L 1 and L 2 are object locking operations targeting the same graphical object G, then Owner(G) = {U 1, U 2 }. If L 1 and L 2 are region locking operations with overlapping region P and non-overlapping regions R 1 and R 2 for L 1 and L 2 then Owner(P) = {U 1, U 2 }, Owner(R 1 ) = {U 1 } and Owner(R 2 ) = {U 2 }. P R1R1 R2R2

If L 1 is an object lock targeting object G and L 2 is a region lock targeting region R, where G is within R, then what should be the lock ownership for G and R? G is inside R, therefore, Owner(R) should also be able to edit G, therefore, Owner(G) = {U 1, U 2 }. U 1 does not own a region lock on R, therefore, Owner(R) = {U 2 }. The resulting effect of G: U 1 can edit G, but cannot move G within R. U 2 can edit G and can move G within R. Both U 1 and U 2 can move G outside of R. If G is moved outside of R, then U 2 loses the ownership on G, i.e. Owner(G) = {U 1 }. R G

Reduce ownership for replicates For any graphical object G with lock that is shared or in the unstable period, conflicts may occur on G. What should be the lock ownership for replicates of G? Consider the following situation: Let O 1 and O 2 be the conflicting operations targeting G, such that O 1 and O 2 are generated by U 1 and U 2 where U 1, U 2  Owner(G). According to replication scheme, replicates G 1 and G 2 will be made for O 1 and O 2 respectively. Shared lock can be assigned to both replicas such that Owner(G 1 ) = Owner(G 2 ) = {U 1, U 2 }. Or exclusive locks can be assigned such that Owner(G 1 ) = {U 1 } and Owner(G 2 ) = {U 2 }. U 1, U 2 U1U1 U2U2 It is better to have exclusive locks than shared locks since conflict cannot occur on objects with an exclusive lock. or replication

Lock ownership for replicated objects Let S be a set of independent operations all targeting the locked object G, such that there is at least a pair of conflicting operations in S. For any user U such that U  Owner(G), then after replication: If U generated an operation O such that O  S, then for any replica G' of G which O is applied to, U  Owner(G'). If U did not generated any operation in S, then U will own the locks for all replicates of G. Consider U 3  Owner(G) generated operation O 3 to edit G. Let O 3 be independent and compatible with both O 1 and O 2. O 3 will be applied to both replicates G 1 and G 2. If U 3 is to own only one replica’s lock, then that replica cannot be consistently chosen at all sites until all independent operations have arrived. U 3 should own the lock on all objects O 3 is applied to. replication U 1, U 2, U 3 U 1, U 3 U 2, U 3

Summary and Future work An optional and responsive locking scheme to reduce conflicts being generated was presented. Highlights: The introduction of region locking. The lock ownership for independent overlapping region and object locks. The introduction of unsafe period for applying independent operations. Taking advantage of object replication to reduce lock ownership. Future work: A good user interface design is needed to display locked items and to allow users to generate locking requests. A new challenge is to provide instantaneous exclusive locking for both region and object locks.