Supporting existing code in a transactional memory system Nate Nystrom Mukund Raghavachari IBM TRAMP 5 Mar 2007

2 Transactional memory Want to use TM for many software engineering reasons: simple concurrent programming model composability avoids common errors: deadlock, priority inversion … But, how does it interact with existing code? atomic { if (a.balance > n) { a.balance -= n; b.balance += n; } atomic { if (a.balance > n) { a.balance -= n; b.balance += n; }

3 Interacting with existing code Existing code may not fit into transactional model Some operations cannot be undone or redone e.g., I/O but maybe encapsulated by operations that can Disparate memory models database transactions explicit synchronization Consistency between TM-managed state and other state Access to existing code can restrict TM implementation Performance implications Working to address these issues in the DALI Project

4 Open operations and compensations Open operations Execute without locking, logging Programmer again responsible for concurrency control Compensations [Garcia-Molina 89] [Weimer, Necula 04] Record closure to be invoke when enclosing transaction rolls back Need to compensate at appropriate level of abstraction can be application, rather than library specific Implemented on top of AtomJava [Grossman, Hindman 05] open { c.executeUpdate(INSERT INTO orders VALUES ( + id... + )); } undo { c.executeUpdate(DELETE FROM orders WHERE oid = + id + ); } open { c.executeUpdate(INSERT INTO orders VALUES ( + id... + )); } undo { c.executeUpdate(DELETE FROM orders WHERE oid = + id + ); }

5 Expanders Use expanders [Warth, Stanojevic, Millstein 06] to simplify adaptation of non-transactional code Methods dispatched through expanders, which specify compensation code expander ListEx of List { void add(Object o) { open { inner.add(o); } undo { inner.remove(o); } }... } use ListEx; List l =...; l.add(x); // -> ListEx.add(x) // -> List.add(x) expander ListEx of List { void add(Object o) { open { inner.add(o); } undo { inner.remove(o); } }... } use ListEx; List l =...; l.add(x); // -> ListEx.add(x) // -> List.add(x)

6 Transaction event listeners Register handlers to be invoked at begin, commit, rollback expander PSEx of PrintStream { PSListener l = new PSListener(inner); void print(String s) { l.sb.append(s); } } class PSListener implements TransactionListener { StringBuffer sb; PrintStream out; void commit(Transaction t) { // flush buffer at outermost commit if (t.parent == null) out.print(sb.toString()); } expander PSEx of PrintStream { PSListener l = new PSListener(inner); void print(String s) { l.sb.append(s); } } class PSListener implements TransactionListener { StringBuffer sb; PrintStream out; void commit(Transaction t) { // flush buffer at outermost commit if (t.parent == null) out.print(sb.toString()); }

7 Integration of software and database transactions Transactions can access both transient and persistent state Use transaction event listeners to: Problems: multiple databases JDBC-specific problems: deadlock, auto-commit At begin:Create a savepoint At rollback:Rollback to savepoint Rollback software transactions At nested commit:Discard savepoint At outermost commit:Commit database transaction If successful commit S/W txn

8 Conclusions Integrating existing code into TM system presents several challenges Compensations, expanders, transaction listeners are abstractions that make this integration easier Implemented database transactions seamlessly Hard issues: Interaction of explicit synchronization and TM Consistency of TM-managed state and other state Strong consistency guarantees with open transactions Performance