The new OSGi R4.2 specification introduces a transaction service. This paves the road to new types of applications dealing with critical resources in a transactional manner. However, despite useful or even required, transactions are often difficult to handle manually, especially in a dynamic environment like OSGi.
This talk presents the new transaction service and how to use it in dynamic environments. To help developers using transactions in a good way, iPOJO hides the most part of transaction management allowing the developer to focus on his business code without worrying about transactions. This talk presents iPOJO transaction support and more specifically:
* How developers can declare transactions as simple as with EJB and
* How the dynamism impact on transactions can be made transparent.
Attendees will learn how to use the new transaction service through a simple example and see how iPOJO transaction support can be used to integrate transactions into business logic in a transparent way.
2. Outline Transactions ??? OSGi Transaction Service (RFC-98) Transaction & Dynamism … From “Hell” to the “EJB3-paradise” 2 Transactional OSGi applications done right
3. Transactions ??? Transactions are a mechanism that allows endowing a sequence of actions with the properties of a single atomic (indivisible) action. 3 Transactional OSGi applications done right
4. Transactions ??? Properties (Failure) Atomicity : the action is performed either entirely or not at all Consistency : from a consistent state to another consistent state Isolation: no intermediate states are visible to any concurrently executing action. Durability: after a transaction has committed, the changes that it made are immune to failures (catastrophes excluded). Transactions are a mechanism that allows endowing a sequence of actions with the properties of a single atomic (indivisible) action. 4 Transactional OSGi applications done right
5. Transactions ?? Transaction Engine commit begin Sequence of actions rollback 5 Transactional OSGi applications done right Uses Resources
6. Why an OSGi Transaction Service ? A lot of OSGi applications deals with Devices Database Remote resources and services => Need transactions to ensure the system consistency 6 Transactional OSGi applications done right
7. OSGi Transaction Service Based on Java Transaction API XA resources Transaction-aware “critical” resources JTA common interfaces are provided as OSGi services User Transaction: programmatic transactions Transaction Synchronization Registry: used by server components such as persistence managers to register synchronization object Transaction Manager: allows the server to control transaction boundaries on behalf of the application being managed. 7 Transactional OSGi applications done right
8. OSGi Transaction Service ServiceReferencetxRef = bundleContext.getServiceReference("javax.transaction.UserTransaction"); UserTransactiontx = (UserTransaction)bundleContext.getService(txRef); // begin transaction tx.begin(); // perform some operations in the context of the transaction try { // Create a transactional resource ConfigResourceconfig = ...; // Perform some transactional work Configuration x = config.createConfiguration("abc"); tx.commit(); // make changes persistent } catch (Throwableth) { tx.rollback(); // rollback changes. } 8 Transactional OSGi applications done right
9. Great … but 9 Transactional OSGi applications done right
10. Dynamism impact … How to automate transaction management ? What happens when a transaction “thread” accesses a service leaving before the end of the transaction ? How to support dynamism with XA resources and volatile resources ? The OSGi Transaction service provides everything to go further ! 10 Transactional OSGi applications done right
11. The “EJB dream” Avoid the developer to manage transactions manually Transaction demarcation:method Transactional method declares the transaction propagation REQUIRED, REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, MANDATORY, NEVER The transaction management is made by the container @TransactionAttribute(REQUIRES_NEW) public void firstMethod() {...} @TransactionAttribute(REQUIRED) public void secondMethod() {...} 11 Transactional OSGi applications done right
12. iPOJO Transaction Supports iPOJO Transaction handler Automates transaction management Allows using transaction just like with EJB @Transaction public class MyClass { @Requires public FooServicefoo; @Transactionnal(propagation="requiresnew") public void firstMethod () { // ... foo.foo(); // Invoke a service //... } @Transactionnal (propagation=“required”) public void secondMethod() {...} // … } 12 Transactional OSGi applications done right
13. iPOJO Transaction and dynamism How to automate transaction management ? The transaction management is made by the container Flexible Allows injecting the current Transaction inside a field Can notify the POJO of the current transaction progress What happens when a transaction “thread” accesses a service leaving before the end of the transaction ? The transaction is roll backed as soon as an instance becomes invalid How to support dynamism inside XA resources and volatile resources ? The Transactional Service Providing handler emulates XA Resources or Volatile resources Experimental… 13 Transactional OSGi applications done right
14. Conclusion Transactions are becoming more and more important inside OSGi applications The Transaction Service is definitely Welcome THANKS ! However, we’ve to take care to avoid the Transaction Nightmare iPOJO proposes EJB-like transaction management reducing the pain ! 14 Transactional OSGi applications done right
15. Questions ? Transactional OSGi applications done right 15 Karl Paulskarl.pauls@akquinet.de Bülowstraße 66, 10783 Berlin+49 151 226 49 845 Dr. Clement Escoffierclement.escoffier@akquinet.de Bülowstraße 66, 10783 Berlin+49 175 246 77 17
Hinweis der Redaktion
Pretty important for all concurrent system dealing with critical and shared resources (database, devices … )
Atomicity : all or nothingConsistency : the system goes from a consistent state to another consistent stateIsolation : the transaction execution is not impacted by any other “Threads”Durability: once completed, can no more be altered