Mustafa Rafiqul Islam
This article describes the transaction model of a Distributed Object Management (DOM) system. The DOM is a distributed active object-oriented environment in which autonomous heterogeneous systems can be integrated and new (non-traditional) applications can be developed. A DOM system appears to be homogeneous distributed object system, in which all objects are expressed in a common object model, even though some of the objects actually represent data and functionality of attached heterogeneous systems. Participating systems in the DOM retain a high degree of autonomy. The systems that participate in this federation may not be forced to change their known behavior, and they cannot be forced to give up local control. In order to support such varied and complex applications provided by the DOM the transaction model of such a system must be very powerful.
Previous research on transactions according to a working taxonomy characterizes a transaction mechanism according to its transaction model and its correctness criterion. Transaction model can be further characterized by transaction structure and object structure. The structure of the individual transaction allowed in the model is defined as transaction structure whereas the structure of objects on which the transactions can operate is defined as object structure. The correctness criterion implies the notion of correctness that is used to achieve a certain degree of concurrency transparency in the system.
DOM’s transaction model combines closed and open nesting with contingency transactions and executes on complex and active objects. In DOM the closed nested transactions are called top transactions which makes its result visible to entire system when it commits. Top transactions can be combined into multitransactions that have some global semantics but permits results to be visible outside the multitransaion. The component transaction of multitransactions may either be vital or no vital. More specialized sutras. it ions are Compensating transactions and Contingency transients. Compensating transactions are defined to undo already committed partial results and Contingency transactions are executed when the primary transaction fails.
The main contribution of this article is to present a transaction model for DOM system. The DOM transaction model that is introduced here is the integration of solutions to individual requirements within a single uniform transaction model. The requirements addressed here are the following. Active capabilities are essential for timely response to events and updates in the environment. This new database model requires monitoring of events and the execution of system-triggered activities within rearming transactions. DOM also requires the support of long-running activities spanning hours, days or even weeks. Therefore, the transaction mechanism must support the sharing of partial results. For completeness, to avoid the failure of a partial task jeopardizing a long activity, it is necessary to differentiate between those that activities that are required for the completion of a transction and those that are not, and to provide for alternative actions in case the primary activity fails. DOM may not have any control over the heterogeneous and autonomous external systems with which DOM activities requires interaction. This requires the DOM to be flexible to cope with activities whose results may become visible and permanent (i.e. committed) before the DOM transaction that spawns them commits. The transaction mechanism must support the execution of compensating actions to undo the effects of committed subtasks. Since DOM is an object-oriented system, the transaction model must deal with abstract operations. It should improve concurrency by using semantic knowledge about the objects and flair abstract operations.
There are significant differences between the transaction models of the current databases and the DOM. There have been many advanced transaction model proposed in current studies from which two dimensions are classified as the transaction structure and object structure. Along with the object structure dimension, simple objects (e.g., files, pages, records), object as instances of abstract data types (ADTs), complex objects, and active objects in increasing complexity are identified. Many of the current processing systems operates on simple objects, mostly on physical pages. The Important feature of this class is that the operations on simple objects do not take into account the semantics of the objects. For example, an update of a page is considered a write on the page, without considering what logical objects is stored on the page. Whereas the DOM transaction model operates on the active objects, which are capable of responding to events by triggering the execution of actions. Since events may be detected while executing a transaction on that object, the execution of the corresponding rule may be spawned as a nested transaction. Because of the capabilities of additional rules firing within a rule execution, nesting of arbitrary depth are also possible in the DOM transaction model.
Along the transaction structure dimension, flat transactions, closed transactions, open nested transactions such as sagas and combination of these forms, in increasing complexity are introduced. Most of the transaction management model in databases that operate on simple objects has concentrated on flat transactions. There are also some transaction model which operates on closed nesting (i.e. Hipace) and open nesting (i.e. Sagas). The DOM’s transaction model can behave as a conventional flat transaction model, it can allows for closed nesting and the execution of triggered processes, or it can be utilized in its most powerful and flexible form by incorporating both open and closed nestlings.
The transaction model of the DOM is presented under a few assumptions. Transactions within a DOM multitransaction are assumed to be executable in parallel, unless specified through a precedence constraint. Also while defining the precedence constraints the commit precedence is assumed to be the default mode with the begin precedence specifiable through rules.
The main advantages • of the DOM transaction model are as following.
It is a complete, distributed, object-oriented transaction model that combines in a single model of capability of handling open nesting, closed nesting, both explicitly and as a result of handling active objects, and Contingency transactions. It is tailor able and can provide as much flexibility as it is required by the applications. It can use the Local Application Interface (LAI) objects as concurrency control placeholders for external repositories.
The disadvantages of this transaction model are as following. As the model is very powerful and flexible implementation of such a system would be very complex. 11 would be difficult to incorporate ultimate measure of performance. Even though the model is formulated in terms of ACTA formalization, a correctness theory should also be developed. The transaction model does not deal with many of the correctness criterion. Temporal dependencies among transactions are not captured by the DOM transaction model. In order to satisfy such dependencies, new correctness criteria and mechanisms for enforcing them have to be developed. Also whether the framework of the taxonomy is completed and minimal is not determined. The notion of consistency will also have to be revised to consider such issues as the locality of consistency (i,e. for which (sub)systems consistency must been forced), the level of consistency supported by the (sub)systems and the timeliness of enforcement. These issues needed to be addressed in the DOM transaction model.
This article would be of major importance for initial studies for transaction model of a Distributed Object Management system. The ideas presented here will be very useful to develop a integrated environment that can promote the interoperation of a large variety of software systems in many application domain. The concept of this transaction model can also be useful for designing heterogeneous and metadata base system. But as mentioned earlier, there are many issues of the DOM transaction model that requires further investigation. For the full heterogeneous system, new notions of consistency must be defined. Relaxations along the lines of locality or timeliness of consistency enforcement must be formalized.
Mustafa Raflqul Iilim B.S.,M.S.(USA)
Is Software Consultant of Flora Ltd., Dhaka. Tel. :
246950, 230491. 231751, 241107, 861416.