Geode Transactions by Swapnil Bawaskar
•Download as PPTX, PDF•
0 likes•281 views
This document summarizes transactions in Apache Geode, including: - The semantics of repeatable read and optimistic concurrency control. - The transaction API for basic, suspend/resume, and single entry operations. - The implementation of using ThreadLocal to isolate transactions and conflict detection at commit. - Handling transactions with replicated and partitioned regions, including failure scenarios. - Support for client-initiated transactions, data colocation, and interaction with other Geode features. - Types of exceptions and how to handle failures.
Report
Share
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
Similar to Geode Transactions by Swapnil Bawaskar
Similar to Geode Transactions by Swapnil Bawaskar (20)
More from PivotalOpenSourceHub
More from PivotalOpenSourceHub (18)
Recently uploaded
Recently uploaded (20)
Geode Transactions by Swapnil Bawaskar
- 2. Agenda • Semantics • Implementation – Replicated Regions – Partitioned Region – From Client • Failure Handling • Road Map 2
- 3. Semantics • Repeatable Read – Thread sees own changes – Other threads do not until commit is called • Optimistic – No Entry level locks, Readers not blocked – Conflict Detection • NOT Persistent (yet) – Not a problem if you have at-least one member up 3
- 4. API BASIC CacheTransactionManager mgr = cache.getCacheTransactionManager(); mgr.begin(); region1.put("K1", "V1"); region1.put("K2", "V2"); region2.put("K2", "V2"); mgr.commit(); SUSPEND/RESUME TransactionId txId = mgr.suspend(); … other non-transactional work mgr.resume(txId); mgr.tryResume(…); SINGLE ENTRY region.putIfAbsent(K, V); region.replace(K, V, V); region.remove(K, V); OTHER mgr.addListener(new MyTransactionListener()); mgr.setWriter(new TransactionWriter()); 4
- 5. Implementation • Isolation through ThreadLocal – Copy existing reference in ThreadLocal – Perform conflict check under lock at commit time Region Thread TXState Entry Reference 5
- 6. At Commit 6
- 7. Notes • copy-on-read must be set to true • D-lock grantor single point of contention • Non-transactional threads may see intermediate state (non atomic) – Reads should be done within a transaction – Set system property Dgemfire.detectReadConflicts=true • Prone to ABA problem • Faster than doing individual operations 7
- 8. Failure Scenarios • Replica Fails – No problem, It will do a GII from other members • Coordinator Fails – Replicas gossip to arrive at the outcome of the transaction • If no member has “Apply Commit” message, some members missing commit set, Abort transaction • If at-least one member has “Apply Commit” message, all members have commit set, apply transaction 8
- 9. PR HostPR Host Thread TX State Partitioned Region 9 PR Host
- 10. PR HostPR Host Thread TX State PR Host Partitioned Region 10
- 11. PR HostPR Host Thread TX State PR Host Partitioned Region 11
- 12. Partitioned Region • TX State on member with Primary copy (TX HOST) • Only one TX Host per transaction – First operation in TX establishes the host – All subsequent operations (even for Replicate Regions) sent to the same host – Throws TransactionDataNotColocatedException if TX Host is not primary • D-lock service is striped – TX Locks are local, no messaging – No single point of contention in the system 12
- 13. Data Colocation • Inspiration “For scalability, applications should manipulate single collection of data that lives on one JVM” - Pat Helland (Life Beyond Distributed Transactions) - Custom Partitioning - Within one Partitioned Region - E.g. All trades in January - Data Colocation - Between Two or more Partitioned Regions - All Orders of a Customer 13
- 14. Failure Scenarios • Failures before Commit – TX Host Crashes (TransactionDataNodeHasDeparted) – On Re-balance (TransactionDataRebalanced) • Entire transaction should be re-tried • Failures after Commit – TX Host Crashes » Replicas would have applied all or none changes » Consistent but Outcome unknown TransactionInDoubt – Replica Crashes, Succeeds 14
- 15. • All operations sent to the server • If necessary, server delegates to primary • HA supported when delegate fails Client Delegate TX Host TX State Client Initiated 15
- 16. Feature Interaction • Eviction/Expiration – Entry is reference counted – Entry kept around if reference count > 0 • OQL – Does not honor Repeatable Read • Persistence – gemfire.ALLOW_PERSISTENT_TRANSACTIONS=true – No delineation on Disk – Works as long as one replica survives • Functions – Can begin, commit, suspend/resume transactions 16
- 17. Handling Failure • Types of Exception – CommitConflictException – TransactionDataNodeHasDepartedException – TransactionDataNotColocatedException – TransactionDataRebalancedException – TransactionInDoubtException • Catch TransactionException and retry in loop 17
- 18. JTA • Enlists as a Synchronization with external JTA Managers – Last to prepare, first to Commit • Has a JCA adapter for Last Resource Commit with Weblogic. • Has an implementation of JTA Manager – not production grade 18
- 19. Road Map • Distributed Transactions (GEODE-16) • XA Data Source • Persistent Transactions • OQL/Query Engine support 19
Editor's Notes
- Isolation level supported by Geode is Repeatable Read. Built for performance, so reads do not block, this causes interesting behavior at commit time, which we will touch upon later. Since there is no lock, check to see if the entry has changed underneath us at commit time, abort tx if it has. In terms of durability, not on disk, but no problem