An Architecture for Integrating Concurrency Control intoEnvironment FrameworksGeorge T. Heineman Gail E. KaiserDepartment of Computer ScienceColumbia UniversityNew York, NY 10027AbstractLayered and componentized systems promise sub-stantial benefits from dividing responsibilities, but itis still unresolved how to construct a system frompre-ezisting, independently developedpieces. Goodsolutions to this problem, in general or for specificclasses of components, should reduce duplicate im-plementation efforts and promote reuse of large scalesubsystems. We tackle the domain of software devel-opment environments and present an architecture forretrofitting external concurrency control componentsonto existing environment frameworks. We describe asample ECC component, explain how we added con-currency control to a commercial product that hadnone, and briefly sketch how we replaced the concur-rency control mechanism of a research system.1 IntroductionMulti-user software development environment frame-works (SDES) need a concurrency control mechanismto detect and resolve conflicts since more than oneuser task may attempt to access the same data inincompatible ways. Many SDES provide some vari-ant of the file checkout paradigm, typically coupledwith versioning, while others incorporate a databasesystem with conventional transactions.SDE ap-plications sometimes require “cooperative transac-tions” (see [2] for a survey of collaborative concur-rency control mechanisms).Cooperative transac-tions make it possible to guarantee atomicity (roll-back of an entire atomic unit if it cannot be com-pleted) and possible to enforce serializability (the ap-Permission to copy without fee all or part of this material isgranted provided that the copies are not made or distributed fordirect commercial advantage, the ACM copyright notice and thetitle of the publication and its date appear, and notice is giventhat copying is by permission of the Association of ComputingMachinery. To copy otherwise, or to republish, requires a feeand/or specific permission.ICSE ’95, Seattle, Washington USAQ 1995 ACM 0-89791 -708-1 /95/0004 ...$3.50pearance that only one user task is accessing the dataat a time). In addition, cooperative transactions canexploit application-specific semantics to resolve con-currency conflicts, often to enhance concurrency andenable collaborative work.Some SDES, however, do not provide any concur-rency control at all, either because the system wasinitially envisioned as supporting only one-user/one-task (at a time) and later extended to multiple con-current tasks with manual synchronization (e.g., pass-ing the “floor” in multi-user editors [7]), or becausethe designers assumed that some external facilitywould provide concurrency control (as for Process-WEAVER [10]). In this paper we present an exter-nal concurrency control (ECC) architect re with ourmain example drawn from the latter category, whereconcurrency control was left for another component.Componentized systems offer potential benefits bydividing the technical and economic responsibilitiesfor providing services; in the case of SDES, theECMA/NIST Reference Model [17] specifies user in-terface, task management, object management, andcommunication components, as well as individualtools. It is still unclear, however, how one can andshould integrate SDE components together to pro-duce a coherent, usable system. we do not attemptto address the entirety of this very large problem: weare concerned primarily with architectures for inte-grating the task management services (TMS) compo-nent of an SDE with ECC; we also discuss integrationof ECC with object management services.In general, TMS components, as described in theliterature, do not specify any particular model ofwhat they require for concurrency control, nordo the(known) implementations provide any pre-defined in-terface to an ECC utility. Thus we must supply aninterface to the ECC from TMS (i.e., entry points)that would cover the plausible range of ECC function-ality, along with an interface from the ECC to TMS(i.e., callbacks) that provides a means forECC toobtain the semantic information required to support305that functionality. In particular, we took the abstractconcept of mediators and made them concrete. Wedevised a generic ECC component with specific entryand callback points that could be directly invoked, orresponded to, by a new system constructed aroundthe component. More significantly, they are designedto be exploited by a mediator (or set of mediators)between ECC and a pre-existing TMS (above) andbetween ECC and a pre-existing OMS (below).From the viewpoint of software architecture, thispaper explores the integration of independently de-veloped, pre-existing components,in contrast to workon (1) construction of systems based on one (or asmall number of) pre-existing components, with therest of the system implemented mostly from scratchto take advantage of these components (the approachtaken for PCTE [19] and many systems in other do-mains,such as Mach [9], Camelot [8], and databaseapplications); or (2) building-block kits, where sets ofcomponents that can be mixed and matched are de-signed and implemented together (e.g., Genesis andAvoca [3]). The most significant difference comparedto the above technologies is that we deal with com-ponentswhose interfaces do not match and whoseinterfaces cannot be modijied to match –much liketrying to fit a square peg in a round hole. Undersuch circumst antes, we argue, integration is possibleby external mediators that overcome the mismatchbetween components (see [18] for a related approachthat assumes components with extension languages).We first present the requirements we have identi-fied, both for the internal concurrency control modelof TMS (perhaps brought out through a mediator)and for interfacing to an ECC component. Then wesketch our prototype ECC component, PERN [14].We demonstrate how we applied our approach to aTMS component without its own concurrency con-trol mechanism. This is followed by a sketch of a laterstudy where we replaced a system’s existing concur-rency control mechanism, and a discussion of lessonslearned. We conclude by summarizing our contribu-tions and directions for future work. Since our focusin this paper is oninterfacing TMS and ECC mecha-nisms, we do not discuss the cooperative transaction~unctionahtg supported by our component (for de-tails, see [14] ); for simplicity, we assume conventionalatomic