Transactional Properties (ACID) • Atomicity – Transaction as indivisible unit-of-work • Consistency – Integrity Constraints on Data • Isolation – Concurrent access should not lead to inconsistency • Durability – Operation effects should persist
Atomicity APP RDBMS DB read(A)=500 read(B)=200 write(A)=500-100=400 write(B)=200+100=300 A = 500 B = 200 ∑=700 ∑=700 ∑'=600 $ $ $ commit ID Balance A 500 B 700 T_ACCOUNT Consistency In the Presence of Failures Tx A B 100$
Consistency ID Balance 1 500 2 700 T_ACCOUNT NOT NULL >=0 ID CITY COUNTRY AC_ID 100 Lisbon Portugal 1 T_ADDRESS FOREGIN KEY Impose Constraints on Data Model
Weak ACID Properties • Benefits of ACID: – Guaranteed consistency – Simple programming model and error semantics • Problem with ACID: – Expensive to implement with distributed resources • How to Scale-Out Data Management? – Limited Scope of Transaction • Atomicity only for resources in same Server – Eventual Consistency • Delay Propagation of Updates Dropping Global Consistency
Slave 2 Master Replicated Data APP Server DB Slave 1 DB DB Write* Read* Read* .us .eu .apj APP Server .us .eu APP Server .apj connect(“master”, [“slave1”, “slave2”]) Synchronize Write* Write* Read* Master-Server Replication
Master 3 Master 1 Clustering APP Server DB Master 2 APP Server APP Server connect([“master1”]) Master-Master Replication LAN DB DB Cluster connect([“master1”, “master2”, “master3”]) Current Primary (for Resource X)
Atomicity with Transactional Log write(A)= 400 write(B)= 300 A = 500 B = 200 commit ID Balance A 500 B 700 T_ACCOUNT Tx Op Row Value 9 W A 500 9 W C 900 9 Commit 10 Rollback 11 W A 400 11 W B 300 11 Commit 12 W C 400 Log/Journal Logging Transaction Operations Tx 11 DB RDBMS APP head tail ID Balance A 400 B 300 Flush Log Truncate Log
Isolation: Versioning APP RDBMS DB A = 500 Optimistic Concurrency Control Tx1 Tx2 A 200$ A 100$ ACK read(A)=500;v=1 read(A)=500;v=1 write(A)=500+100=600;v=1 write(A)=500+200=700;v=1 commit rollback ∑=700 v=1 v=2 $ Rollback ID Balance Version A 700 2 B 300 1 T_ACCOUNT
DB DB Two-Phase Commit Protocol (XA) TxMgr Resource Mgr Coordinator Prepare x N Pre-commit 1 Pre-commit N Commit x N phase 1 phase 2 Pre-commit (keep logs & locks)
Server 3 Server 1 Primary (Master) Auto-Failover DB Server 2 Heartbeat & Elections DB DB Previous Primary (for Resource X) $ ♥ ♥ ♥ $ $ Election New Primary (for Resource X) $ $
Transaction Management • Transaction scope may include: – Multiple calls to the same DAO – Operations in different DAOs – Operations in different Resources (JTA) • Data-Access Technology Independence: – Service-Layer Implementation – DAO API • Connection Must be Shared – Thread/Request Contextualized Service Layer Data-Access Layer Issues
Transactional Interceptor ServiceImpl DAO Transactional Interceptor TransactionManager Proxy begin() commit() Client Object DB AOP – with Proxy Power Service Thread-Safe
Transaction Management Annotation-Driven Declarative Demarcation @Singleton public class TransferServiceImpl implements TransferService { @Inject private AccountRepository accountRepository; @Inject private OperationsRepository operationsRepository; @Transactional public Transfer transfer(Long creditId, Long debitId, BigDecimal amount) { // Do transfer with AccountRepository ... // Write confirmation with OperationsRepository ... ... } }
Transaction Management Local Transaction Propagation @Singleton public class TransferServiceImpl implements TransferService { ... @Transactional public Transfer transfer(...) { // do transfer // write confirmation with OperationsRepository ... … emailService.send(msg); } } @Singleton public class EmailServiceImpl implements EmailService { @Transactional public void send(Message msg) { ... } } method1 method2 TX 1 TX 1 TX 2
Transactions in Spring Configuration @Configuration @EnableTransactionManagament @Import({JdbcConfig.class, JpaConfig.class, DBConfig.class}); @ComponentScan(“myapp.services”) @PropertySource(“app.properties”) public class AppConfig { … } @Configuration @Profile(“jdbc”) public class JdbcConfig { @Bean PlatformTransactionManager txMgr(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } } @Configuration @Profile(“jpa”) public class JpaConfig { … } import org.springframework.context.annotation.*;
MongoDB • Limited Transactions Scope – Operations in Single Document – No Atomicity Across Documents&Servers – Distributed ACID also available (but expensive) • Read on Secondary Servers might not be latest – Not Propagated yet from Primary Transactions WRITE_CONCERN
GemFire Data-Model Cache Data Control TransactionListener Region Region Region Region Region Control CacheListener CacheLoader CacheWriter Region: “books” Data Entry Key Value Meta-Data Entry Key Value Meta-Data DB Region java.util.Map
GemFire Transactions Propagatation and Concurrency Control Replicated&Distributed a.acme.com “Stocks” b.acme.com “Stocks” c.acme.com “Stocks” Scope Propagation Wait Concurrency Control Local No NO None Distributed YES NO None Distributed+ACK YES YES Versions
JTA Java Transactions Architecture JDBC Resource Drivers JMS Connection JDBC XA XA Resource (adaptors) JMS XA DB Broker Msg Broker DB JTA TxMgr APP Global TX • Application Server • Standalone App JEE
JTA - API @Stateless @TransactionManagement(BEAN) public class StockServiceImpl implements StockService { @Resource private UserTransaction tx; @Resource private DataSource dataSource; @Resource private ConnectionFactory connectionFactory; public void foo() { tx.begin(); // Do work on dataSource // Do work on connectionFactory tx.commit(); } } EJB Model
LDAP • Naming and Directory Service • Structure Names Data-Model • Keeps many types of Information: – Organizational – Users – Security Policy – Custom • No native support for ACID Transactions – Only Durability and Consistency Rules
Spring LDAP • Simplified API to connect and interact with LDAP server • Emulates Transactions using Compensatory Undo Operations – Atomicity Only – Programatic API – Integrated with Declarative @Transactional • No concurrency control (isolation) – Except if conflict detected by app and rollback
Conclusions • Transactions are very often essential – For Reliability and Consistency • Multiple Kinds of Transactional Resources • Distribution of Transactions is Expensive – Trade-off: Scalability vs. Consistency vs. Availability • Basic Mechanisms Well-Understood – Many optimizations possible • AOP Simplifies Transaction Management Thank You