bjhargrave
commented
16 years ago Comment author: Pavlin Dobrev <p.dobrev@prosyst.com>
The MEG has created a number of services that have transactional needs but without implementing real transaction model. EEG also will need transaction behavior for its services. This RFC proposes to centralize the necessary signaling of transaction. The RFC argues for a limited transaction model that supports the use cases of an embedded and constrained environment. This implies no explicit crash recovery and a smaller API then the Java Transaction API
This RFC introduces the transaction concepts and outlines the different trade-offs that need to be made in the API.
Requirements Provide a comprehensive model that allows components in an OSGi Service Platform to perform their actions in a transaction way.
- Provide a set of APIs that define a Transaction Manager that can delineate transactions, commit, and rollback transactions together with a possibility for resource managers to join a transaction
- May provide centralized locking facility. (Current API doesn’t provide Locking mechanism. It is required that each resource participating in the transaction to define it’s own locking and isolation level).
- The transaction API must allow implementations to run on embedded systems
- There is no need for crash recovery because of its demand on fast persistent memory. This implies that a failure inside a transaction does not have to be recovered.
- The Transaction System may support a recovery concept, which allows the system to recover from power fails or accidental system shutdown.
- The API must be compatible with JTA as much as possible. This means that method names must be equal for equal cases so it is easy to reuse JTA implementations on an OSGi system. This allows developers, which are already familiar with the JTA to have the same experience using the OSGi transactional system, without the need of additional training. The similarity between these two APIs would also allow implementation of a transaction system that interoperates with the two models – the JTA and the OSGi transaction model.
- The model of the Transaction Manager must allow implementation of a transactional system, without modifying the existing API. As example a transaction-enabled CM implementation will still be compatible with the OSGi API, but will also participate in transaction started by the applications.
- The system must implements the four important features of the transactional system – ACID (Atomicity, Consistency, Isolation, Durability). This ensures that critical operations, executed within a transaction cannot break the stability and will leave the system in consistent state.
- In addition to the JTA, the OSGi Transactional model must provide isolation between the different components that participate in transaction, by allowing only the transaction owner to manage actively the state of the transaction. This is required because of the dynamic nature and various components that may exist in the OSGi environment.
- The transactional systems usually require more resources for proper operation. However, an embedded systems, which are one of the typical OSGi installations has a lot of resource constraints. Therefore, the API should allow the vendor to restring the access to the transactional system by a set of permissions, that allows only trusted components to start or participate in transactions.
Original bug ID: BZ#577 From: Pavlin Dobrev <p.dobrev@prosyst.com> Reported version: R4 V4.2