Transaction management across data stores

Companies have evolved from a world where they only had SQL databases to a world where they use different kinds of data stores, such as key­value data stores, document­oriented data stores and graph databases. The reason why they have started to introduce this diversity of persistency models is because different NoSQL technologies bring different data models with associated query languages and/or APIs. However, they are confronted now with a problem in which they have the data scattered across different data stores. This problem lies in that when a business action requires to update the data, the data reside in different data stores, and they are subject to inconsistencies in the event of failure and/or concurrent access. These inconsistencies appear due to the lack of transactional consistency that was guaranteed in traditional SQL databases but is not guaranteed either within the NoSQL data stores or across data stores and databases. CoherentPaaS comes to remedy this need. CoherentPaaS provides an ultra­scalable transactional management layer that can be integrated with any data store with multi­ versioning capabilities. The layer has been integrated with six different data stores, three NoSQL data stores and three SQL­like databases. In this paper, we describe this generic ultra­scalable transactional management layer and focus on its API and how it can be integrated in different ways with different data stores and databases

Mobile transaction management in mobisnap

Lecture Notes in Computer Science, 1884To allow mobile users to continue their work while disconnected, mobile systems usually rely on optimistic replication techniques. In mobile database systems, mobile units cache subsets of the database state and allow disconnected users to perform transactions concurrently. These transactions are later integrated in the master database state. As concurrently performed transactions may conflict, it is usually impossible to determine the result of an update in the mobile unit. Moreover, this model differs from the traditional client/server model due to the fundamental fact that the user will usually not be connected to the system when the results of his transactions are finally determined - therefore, he can not immediately perform adequate alternative actions. In this paper we describe a transaction management system that takes into consideration the above-mentioned characteristics. Transactions are specified as mobile transactional programs, which allows the precise definition of operation semantics and the definition of alternative actions. Support for active user notification is also provided in the system. Finally, the system relies on a reservation mechanism to be able to guarantee the results of transactions in the mobile units.(undefined

Analysis of Transaction Management Performance

There is currently much interest in incorporating transactions into both operating systems and general purpose programming languages. This paper provides a detailed examination of the design and performance of the“¢ transaction manager of the Camelot system. Camelot is a transaction facility that provides a rich model of transactions intended to support a wide variety of general-purpose applications. The transaction manager's principal function is to execute the protocols that ensure atomicity. The conclusions of this study are: a simple optimization to two-phase commit reduces logging activity of distributed transactions; non-blocking commit is practical for some applications; multithreaded design improves throughput provided that log batching is used; multi-casting reduces the variance of distributed commit protocols in a LAN environment; and the performance of transaction mechanisms such as Camelot depend heavily upon kernel performance

Transaction Management Model for Mobile Database

Transaction support is crucial in mobile data management. Specific characteristics of mobile environments (e.g. variable bandwidth, disconnections, and limited resources on mobile hosts) make traditional transaction management techniques no longer appropriate. This is due the fact that the Atomicity, Consistency, Isolation and Durability (ACID) properties of transactions are not simply followed, in particular the consistency property. Thus, transaction management models adopting weaker form of consistency are needed and these models can now tolerate a limited amount of consistency. As a result, several transaction management models for mobile databases have been proposed, each of which has attempted to overcome some issues pertaining to transaction processing in mobile environment. However, issues such as (a) only one mobile host (MH) is allowed to update the data item (b) large number of rejected transactions (c) commit time execution of transactions at mobile host (MH) is large are not well handled. The proposed the model with the aims at solving the stated issues. The main idea underlying the model is that transaction execution can be done at the base station (BS) and mobile host (MHs). Transactions at a MH can update data locally and then precommit. When the MH connects to the BS, these pre-committed transactions are sent to the BS and re-executed as base transactions (BT) to maintain data consistency at the BS. BTs are serialized on the master data stored at the BS. This will results in data consistency. The availability of data item at MHs makes the execution of transaction at MHs possible. Each MH is allocated some value of data item, and the rest of it is kept at the base server. By having the own this resource, a transaction at a MH is allowed to update the data item within the limit of iSi. The model has been implemented and the result has shown that the model works correctly as expected

Advanced Architectures for Transactional Workflows or Advanced Transactions in Workflow Architectures

In this short paper, we outline the workflow management systems research in the Information Systems division at the University of Twente. We discuss the two main themes in this research: architecture design and advanced transaction management. Attention is paid to the coverage of these themes in the context of the completed Mercurius and WIDE projects and in the new CrossFlow project. In the latter project, contracts are introduced as a new theme to support electronic commerce aspects in workflow management

TRANSACTION MANAGEMENT SYSYEM FOR A PUBLISHER

Managing the day-to-day operations of a publishing house isn\u27t easy. For example, it\u27s hard to keep track of stocks, manage vendor orders, and maintain transaction records. Our project titled Transaction Management System aims to solve these problems by offering a single tool that helps standardize and digitize publishing operations. It assists in automating and improving the efficiency of the various processes involved in a publishing house. The Transaction Management System is a full-stack web application that can be accessed through an internet browser. The user experience and interface are simple and easy to use so that users can find information quickly and complete tasks easily. The system gets rid of the need for handwritten records and papers, which can take time and lead to mistakes. With this, producers can focus primarily on creating great content and let the system handle the management tasks

Standard setting and competition in securities settlement

This paper examines the impact of messaging and technical standards on competition in the supply of se-curities transaction management services. Two simple switching cost models are used to clarify the im-pact of standards on barriers to entry and on the incentives to adopt harmonised and simplified securities processing standards. Policy implications are discussed briefly.securities settlement; standards; inter-operability; switching costs