1. Scaling up & out with
Ehcache and Terracotta
Alex Snaps
Senior Software Engineer — Terracotta, Inc.

2. What’s this all about ?
Rethink caching, rethink access patterns and, finally …
Know what solution is right for your application to deal with lots of data !

3. Agenda
 Ehcache ? Terracotta ?
 Data access patterns revisited
 Scaling Up vs. Out
 Consistency consideration
 Search
 Inversion of control (sort of!)
Q&A
JeeConf 2011 — Kiev 3

4. Who’s who ?
… on Ehcache, Terracotta and… last & least, me.

5. Ehcache
JeeConf 2011 — Kiev 5

6. Ehcache
 The most widely used performance library in Java
– Used in over 70 percent of enterprise Java applications
– 200k + production deployments
– Embedded in most popular Java frameworks/apps.
Hibernate, Spring, Liferay, JIRA, ColdFusion, Grails...
JeeConf 2011 — Kiev 5

7. Ehcache
 The most widely used performance library in Java
– Used in over 70 percent of enterprise Java applications
– 200k + production deployments
– Embedded in most popular Java frameworks/apps.
Hibernate, Spring, Liferay, JIRA, ColdFusion, Grails...
 Fast
JeeConf 2011 — Kiev 5

8. Ehcache
 The most widely used performance library in Java
– Used in over 70 percent of enterprise Java applications
– 200k + production deployments
– Embedded in most popular Java frameworks/apps.
Hibernate, Spring, Liferay, JIRA, ColdFusion, Grails...
 Fast
 Lightweight
– Less than 1 MB
– Easy to use API
JeeConf 2011 — Kiev 5

9. Ehcache
 The most widely used performance library in Java
– Used in over 70 percent of enterprise Java applications
– 200k + production deployments
– Embedded in most popular Java frameworks/apps.
Hibernate, Spring, Liferay, JIRA, ColdFusion, Grails...
 Fast
 Lightweight
– Less than 1 MB
– Easy to use API
 Grows with your application with only two lines of configuration
– Scale Up - BigMemory (100’s of Gig, in process, NO GC)
– Scale Out - Clustering Platform (Up to 2 Terabytes, HA)
JeeConf 2011 — Kiev 5

10. Ehcache
 The most widely used performance library in Java
– Used in over 70 percent of enterprise Java applications
– 200k + production deployments
– Embedded in most popular Java frameworks/apps.
Hibernate, Spring, Liferay, JIRA, ColdFusion, Grails...
 Fast
 Lightweight
– Less than 1 MB
– Easy to use API
 Grows with your application with only two lines of configuration
– Scale Up - BigMemory (100’s of Gig, in process, NO GC)
– Scale Out - Clustering Platform (Up to 2 Terabytes, HA)
 Fully backward compatible all the way back to 1.x
JeeConf 2011 — Kiev 5

11. Terracotta
JeeConf 2011 — Kiev 6

12. Terracotta
 Founded 2003 in San Francisco, CA
JeeConf 2011 — Kiev 6

13. Terracotta
 Founded 2003 in San Francisco, CA
 Present in India, Europe
and pretty much all over the globe!
JeeConf 2011 — Kiev 6

14. Terracotta
 Founded 2003 in San Francisco, CA
 Present in India, Europe
and pretty much all over the globe!
 Open source project that delivers
Enterprise Java application scalability and availability
JeeConf 2011 — Kiev 6

15. Terracotta
 Founded 2003 in San Francisco, CA
 Present in India, Europe
and pretty much all over the globe!
 Open source project that delivers
Enterprise Java application scalability and availability
 Products around :
– Ehcache & Hibernate
– Quartz Scheduler
– Web Sessions
– Terracotta Toolkit
JeeConf 2011 — Kiev 6

16. About me …
JeeConf 2011 — Kiev 7

17. About me …
 Senior Software Engineer at Terracotta
– Working on Ehcache & Terracotta integration,
– Quartz Enterprise Scheduler,
– Terracotta toolkit
JeeConf 2011 — Kiev 7

18. About me …
 Senior Software Engineer at Terracotta
– Working on Ehcache & Terracotta integration,
– Quartz Enterprise Scheduler,
– Terracotta toolkit
 Contributed to
– Hibernate
– Unitils & dbMaintain
– ... and a couple of long forgotten open source projects
JeeConf 2011 — Kiev 7

19. About me …
 Senior Software Engineer at Terracotta
– Working on Ehcache & Terracotta integration,
– Quartz Enterprise Scheduler,
– Terracotta toolkit
 Contributed to
– Hibernate
– Unitils & dbMaintain
– ... and a couple of long forgotten open source projects
 Speak at JUGs & conferences
– like Codemotion, jFokus, JavaOne,
JavaZone, Devoxx, Jazoon, ...
JeeConf 2011 — Kiev 7

20. Now to the fun part!
Data access patterns revisited

21. Big Data ?
JeeConf 2011 — Kiev 9

22. Big Data ?
 What's Big Data for you?
JeeConf 2011 — Kiev 9

23. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
JeeConf 2011 — Kiev 9

24. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
– Gigabytes?
JeeConf 2011 — Kiev 9

25. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
– Gigabytes?
– Terabytes?
JeeConf 2011 — Kiev 9

26. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
– Gigabytes?
– Terabytes?
– Petabytes?
JeeConf 2011 — Kiev 9

27. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
– Gigabytes?
– Terabytes?
– Petabytes?
 It's all about supporting your business growth.
JeeConf 2011 — Kiev 9

28. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
– Gigabytes?
– Terabytes?
– Petabytes?
 It's all about supporting your business growth.
– Growth in terms of schema evolution.
JeeConf 2011 — Kiev 9

29. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
– Gigabytes?
– Terabytes?
– Petabytes?
 It's all about supporting your business growth.
– Growth in terms of schema evolution.
– Growth in terms of data storage.
JeeConf 2011 — Kiev 9

30. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
– Gigabytes?
– Terabytes?
– Petabytes?
 It's all about supporting your business growth.
– Growth in terms of schema evolution.
– Growth in terms of data storage.
 Growth in terms of data processing.
JeeConf 2011 — Kiev 9

31. Big Data ?
 What's Big Data for you?
 Not a question of quantity.
– Gigabytes?
– Terabytes?
– Petabytes?
 It's all about supporting your business growth.
– Growth in terms of schema evolution.
– Growth in terms of data storage.
 Growth in terms of data processing.
 Is your data stack capable of handling such a growth?
JeeConf 2011 — Kiev 9

32. Where’s all that data ?
Relational databases & friends

33. How do you access your database ?
JeeConf 2011 — Kiev 11

34. How do you access your database ?
JeeConf 2011 — Kiev 11

35. Caching
JeeConf 2011 — Kiev 12

36. Caching
 If going to the database is so
expensive...
... we should just avoid it!
JeeConf 2011 — Kiev 12

37. Caching
 If going to the database is so
expensive...
... we should just avoid it!
 Put a cache in front of the
database
JeeConf 2011 — Kiev 12

38. Caching
 If going to the database is so
expensive...
... we should just avoid it!
 Put a cache in front of the
database
JeeConf 2011 — Kiev 12

39. Caching
 If going to the database is so
expensive...
... we should just avoid it!
 Put a cache in front of the
database
 Data remains closer to
processing unit
JeeConf 2011 — Kiev 12

40. Cache in front of the database
JeeConf 2011 — Kiev 13

41. Cache in front of the database
RDBMS
READ
 Helps scale your read operations Cache
READ
PowerBook G4
JeeConf 2011 — Kiev 13

42. Cache in front of the database
RDBMS
READ
 Helps scale your read operations Cache
– Writes go directly to the database
WRITE
READ
PowerBook G4
JeeConf 2011 — Kiev 13

43. SoR aware caching
 What about multithreaded cache misses
for a same key …
– You want to avoid hitting the system of record twice!
 SelfPopulating
caches
know how to fetch data on misses
– Blocking concurrent accesses to missing keys
– While only one thread populates the Cache
 But what about invalidation ?
JeeConf 2011 — Kiev 14

44. Cache in front of the database
JeeConf 2011 — Kiev 15

45. Cache in front of the database
 Helps scale your read operations
JeeConf 2011 — Kiev 15

46. Cache in front of the database
 Helps scale your read operations
– Writes go directly to the database
JeeConf 2011 — Kiev 15

47. Cache in front of the database
 Helps scale your read operations
– Writes go directly to the database
 Introducing Cache Writers
JeeConf 2011 — Kiev 15

48. Cache in front of the database
 Helps scale your read operations WRITE RDBMS
READ
– Writes go directly to the database Cache
 Introducing Cache Writers
– Writes are being done to the Cache WRITE READ
PowerBook G4
JeeConf 2011 — Kiev 15

49. Write-through
RDBMS
Cache
Application
code
JeeConf 2011 — Kiev

50. Write-through
RDBMS
Cache
Application
code
JeeConf 2011 — Kiev

51. Write-through
RDBMS
Cache
Application
code
JeeConf 2011 — Kiev

52. Write-through
RDBMS
Cache
Application
code
JeeConf 2011 — Kiev

53. Write-behind
JeeConf 2011 — Kiev 17

54. Write-behind
 Rather than write changes directly
to the slowest participant
JeeConf 2011 — Kiev 17

55. Write-behind
 Rather than write changes directly
to the slowest participant
– Write to faster durable store (persistent queue)
JeeConf 2011 — Kiev 17

56. Write-behind
 Rather than write changes directly
to the slowest participant
– Write to faster durable store (persistent queue)
• required for recovery in the face of failure
JeeConf 2011 — Kiev 17

57. Write-behind
 Rather than write changes directly
to the slowest participant
– Write to faster durable store (persistent queue)
• required for recovery in the face of failure
– Only write to database later
JeeConf 2011 — Kiev 17

58. Write-behind
 Rather than write changes directly
to the slowest participant
– Write to faster durable store (persistent queue)
• required for recovery in the face of failure
– Only write to database later
• in batches and/or coalesced
JeeConf 2011 — Kiev 17

59. Write-behind
 Rather than write changes directly
to the slowest participant
– Write to faster durable store (persistent queue)
• required for recovery in the face of failure
– Only write to database later
• in batches and/or coalesced
 In
a distributed environment handling failures
we enforce happens at least once
JeeConf 2011 — Kiev 17

60. Write-behind
 Rather than write changes directly
to the slowest participant
– Write to faster durable store (persistent queue)
• required for recovery in the face of failure
– Only write to database later
• in batches and/or coalesced
 In
a distributed environment handling failures
we enforce happens at least once
– loosens the contract vs. "once and only once"!
JeeConf 2011 — Kiev 17

61. Write-behind
RDBMS
Cache
Application
code
JeeConf 2011 — Kiev

62. Write-behind
RDBMS
Cache
Application
code
JeeConf 2011 — Kiev

63. Write-behind
RDBMS
Cache Writer
Application
code
JeeConf 2011 — Kiev

64. Write-behind
RDBMS
Cache Writer
Application
code
JeeConf 2011 — Kiev

65. Write-behind
RDBMS
Cache Writer
Application
code
JeeConf 2011 — Kiev

66. Write-behind
RDBMS
Cache Writer
Application
code
JeeConf 2011 — Kiev

67. Write-behind
RDBMS
Cache Writer
Application
code
JeeConf 2011 — Kiev

68. Write-behind
RDBMS
Cache Writer
Application
code
JeeConf 2011 — Kiev

69. Write-behind
RDBMS
Cache Writer
Application
code
JeeConf 2011 — Kiev

70. Write-behind
RDBMS
Writer
Cache Writer
Application
code
JeeConf 2011 — Kiev

71. Write-behind
RDBMS
Writer
Cache Writer
Application
code
JeeConf 2011 — Kiev

72. Write-behind
JeeConf 2011 — Kiev 19

73. Write-behind
 Very configurable
JeeConf 2011 — Kiev 19

74. Write-behind
 Very configurable
– Batching & Coalescing
JeeConf 2011 — Kiev 19

75. Write-behind
 Very configurable
– Batching
& Coalescing
– Maximum delay between each write
JeeConf 2011 — Kiev 19

76. Write-behind
 Very configurable
– Batching & Coalescing
– Maximum delay between each write
– Limit the writes per seconds
JeeConf 2011 — Kiev 19

77. Write-behind
 Very configurable
– Batching & Coalescing
– Maximum delay between each write
– Limit the writes per seconds
– Retry configuration
JeeConf 2011 — Kiev 19

78. Write-behind
 Very configurable
– Batching & Coalescing
– Maximum delay between each write
– Limit the writes per seconds
– Retry configuration
JeeConf 2011 — Kiev 19

79. Write-behind
 Very configurable
– Batching & Coalescing
– Maximum delay between each write
– Limit the writes per seconds
– Retry configuration
 New as of Ehcache 2.4
JeeConf 2011 — Kiev 19

80. Write-behind
 Very configurable
– Batching & Coalescing
– Maximum delay between each write
– Limit the writes per seconds
– Retry configuration
 New as of Ehcache 2.4
– writeBehindConcurrency="3"
JeeConf 2011 — Kiev 19

81. Write-behind
 Very configurable
– Batching & Coalescing
– Maximum delay between each write
– Limit the writes per seconds
– Retry configuration
 New as of Ehcache 2.4
– writeBehindConcurrency="3"
– writeBehindMaxQueueSize="500"
JeeConf 2011 — Kiev 19

82. Scaling the database
JeeConf 2011 — Kiev 20

83. Scaling the database
JeeConf 2011 — Kiev 20

84. Scaling the cache
JeeConf 2011 — Kiev 21

85. Scaling the cache
JeeConf 2011 — Kiev 21

86. BigMemory
JeeConf 2011 — Kiev 22

87. BigMemory
 OffHeap storage
– But in process memory
JeeConf 2011 — Kiev 22

88. BigMemory
 OffHeap storage
– But in process memory
 Uses DirectByteBuffer
JeeConf 2011 — Kiev 22

89. BigMemory
 OffHeap storage
– But in process memory
 Uses DirectByteBuffer
 Faults unused elements out of heap,
and in again, transparently
– …and from or to the disk store as well
JeeConf 2011 — Kiev 22

90. BigMemory
 OffHeap storage
– But in process memory
 Uses DirectByteBuffer
 Faults unused elements out of heap,
and in again, transparently
– …and from or to the disk store as well
 Holds hundreds of gigabytes of data
– 320Gb tested on a single machine
JeeConf 2011 — Kiev 22

91. Large data on a single VM
JeeConf 2011 — Kiev 23

92. Distributed Caching
JeeConf 2011 — Kiev 24

93. Distributed Caching
 What if data isn't perfectly
partitioned ?
JeeConf 2011 — Kiev 24

94. Distributed Caching
 What if data isn't perfectly
partitioned ?
 How do we keep this all
in sync ?
JeeConf 2011 — Kiev 24

95. Distributed Caching
 What if data isn't perfectly
partitioned ?
 How do we keep this all
in sync ?
 Peer-to-peer ?
JeeConf 2011 — Kiev 24

96. Distributed Caching
JeeConf 2011 — Kiev 25

97. Distributed Caching
 Cached data remains
close to the processing
unit
JeeConf 2011 — Kiev 25

98. Distributed Caching
 Cached data remains
close to the processing
unit
 Central unit
orchestrates it all
JeeConf 2011 — Kiev 25

99. Distributed Caching
JeeConf 2011 — Kiev 26

100. Distributed Caching
JeeConf 2011 — Kiev 27

101. Distributed Caching
JeeConf 2011 — Kiev 28

102. DCV2
JeeConf 2011 — Kiev 29

103. DCV2
 Simple storage change in the cache config
– <terracotta storageStrategy=”DCV2” />
JeeConf 2011 — Kiev 29

104. DCV2
 Simple storage change in the cache config
– <terracotta storageStrategy=”DCV2” />
 All keys and values are stored on the server
– With a local cache (enabled by default)
JeeConf 2011 — Kiev 29

105. DCV2
 Simple storage change in the cache config
– <terracotta storageStrategy=”DCV2” />
 All keys and values are stored on the server
– With a local cache (enabled by default)
 With a TSA
– holds Terabytes of data!
JeeConf 2011 — Kiev 29

106. Consistency considerations
From Happens-Before to ACID to 2PC and… back!

107. The ACID guarantees
JeeConf 2011 — Kiev 31

108. The ACID guarantees
 Let people easily reason about the problem
JeeConf 2011 — Kiev 31

109. The ACID guarantees
 Letpeople easily reason about the problem
 Atomic
– We see all changes, or no changes at all
JeeConf 2011 — Kiev 31

110. The ACID guarantees
 Letpeople easily reason about the problem
 Atomic
– We see all changes, or no changes at all
 Consistent
– Changes respect our rules and constraints
JeeConf 2011 — Kiev 31

111. The ACID guarantees
 Letpeople easily reason about the problem
 Atomic
– We see all changes, or no changes at all
 Consistent
– Changes respect our rules and constraints
 Isolated
– We see all changes as independently happening
JeeConf 2011 — Kiev 31

112. The ACID guarantees
 Letpeople easily reason about the problem
 Atomic
– We see all changes, or no changes at all
 Consistent
– Changes respect our rules and constraints
 Isolated
– We see all changes as independently happening
 Durable
– We keep the effect of our changes forever
JeeConf 2011 — Kiev 31

113. The ACID guarantees
 Letpeople easily reason about the problem
 Atomic
– We see all changes, or no changes at all
 Consistent
– Changes respect our rules and constraints
 Isolated
– We see all changes as independently happening
 Durable
– We keep the effect of our changes forever
 Fits a simplified model of our reality
JeeConf 2011 — Kiev 31

114. ... and that’s what you get
JeeConf 2011 — Kiev 32

115. ... and that’s what you get
 ... when using Hibernate
– Using read-write strategy
– Falls back to DB to resolve isolation level
– Transactional leaves it to the cache to be ACI(D)
• And requires an XA environment, including all overhead!
JeeConf 2011 — Kiev 32

116. ... and that’s what you get
 ... when using Hibernate
– Using read-write strategy
– Falls back to DB to resolve isolation level
– Transactional leaves it to the cache to be ACI(D)
• And requires an XA environment, including all overhead!
 But using Ehcache API directly
– Youget the JMM guarantees
– Cached values are not inherently thread-safe
JeeConf 2011 — Kiev 32

117. Basic tools
JeeConf 2011 — Kiev 33

118. Basic tools
 Blocking & SelfPopulatingCache constructs
– Will
not let multiple threads populate
the cache with the same key
JeeConf 2011 — Kiev 33

119. Basic tools
 Blocking & SelfPopulatingCache constructs
– Willnot let multiple threads populate
the cache with the same key
 Explicit Locking API
– acquire ( Read | Write ) LockOnKey
– releaseLockOnKey
– try ( Read | Write ) LockOnKey
JeeConf 2011 — Kiev 33

120. Atomic Operations
JeeConf 2011 — Kiev 34

121. Atomic Operations
 Atomic operations on Cache
– putIfAbsent(Element): Element
– removeElement(Element): Element
– replace(Element, Element): boolean
– replace(Element): boolean
JeeConf 2011 — Kiev 34

122. Atomic Operations
 Atomic operations on Cache
– putIfAbsent(Element): Element
– removeElement(Element): Element
– replace(Element, Element): boolean
– replace(Element): boolean
 Copy on read & copy on write caches
– Configurable per cache
copyOnRead=”true” copyOnWrite=”false”
– Configurable CopyStrategy per caches
• Can be used with custom ElementValueComparator
JeeConf 2011 — Kiev 34

123. Transactional caches
JeeConf 2011 — Kiev 35

124. Transactional caches
 When you need rollback!
JeeConf 2011 — Kiev 35

125. Transactional caches
 Whenyou need rollback!
 Comes in three flavors:
– local
– xa
– xa_strict
JeeConf 2011 — Kiev 35

126. Transactional caches
 Whenyou need rollback!
 Comes in three flavors:
– local
– xa
– xa_strict
 Very simple configuration per Cache configuration
– transactionalMode=”local”
JeeConf 2011 — Kiev 35

127. Transactional caches
 Whenyou need rollback!
 Comes in three flavors:
– local
– xa
– xa_strict
 Very simple configuration per Cache configuration
– transactionalMode=”local”
 Only accessible within a Transaction
JeeConf 2011 — Kiev 35

128. Transactional caches
 Whenyou need rollback!
 Comes in three flavors:
– local
– xa
– xa_strict
 Very simple configuration per Cache configuration
– transactionalMode=”local”
 Onlyaccessible within a Transaction
 They will copy on read and copy on write
JeeConf 2011 — Kiev 35

129. Transactional caches
 Whenyou need rollback!
 Comes in three flavors:
– local
– xa
– xa_strict
 Very simple configuration per Cache configuration
– transactionalMode=”local”
 Onlyaccessible within a Transaction
 They will copy on read and copy on write
 When clustered, cache must be coherent
JeeConf 2011 — Kiev 35

130. Local transaction
JeeConf 2011 — Kiev 36

131. Local transaction
 Cheap!
JeeConf 2011 — Kiev 36

132. Local transaction
 Cheap!
 Requires you to do the demarcation
JeeConf 2011 — Kiev 36

133. Local transaction
 Cheap!
 Requires you to do the demarcation
transactionController
= cacheManager.getTransactionController();
JeeConf 2011 — Kiev 36

134. Local transaction
 Cheap!
 Requires you to do the demarcation
transactionController
= cacheManager.getTransactionController();
transactionController.begin();
JeeConf 2011 — Kiev 36

135. Local transaction
 Cheap!
 Requires you to do the demarcation
transactionController
= cacheManager.getTransactionController();
transactionController.begin();
cache1 = cacheManager.getEhcache("txCache1");
JeeConf 2011 — Kiev 36

136. Local transaction
 Cheap!
 Requires you to do the demarcation
transactionController
= cacheManager.getTransactionController();
transactionController.begin();
cache1 = cacheManager.getEhcache("txCache1");
cache1.put(new Element(1, putValue));
JeeConf 2011 — Kiev 36

137. Local transaction
 Cheap!
 Requires you to do the demarcation
transactionController
= cacheManager.getTransactionController();
transactionController.begin();
cache1 = cacheManager.getEhcache("txCache1");
cache1.put(new Element(1, putValue));
cache2 = cacheManager.getEhcache("txCache2");
JeeConf 2011 — Kiev 36

138. Local transaction
 Cheap!
 Requires you to do the demarcation
transactionController
= cacheManager.getTransactionController();
transactionController.begin();
cache1 = cacheManager.getEhcache("txCache1");
cache1.put(new Element(1, putValue));
cache2 = cacheManager.getEhcache("txCache2");
cache2.remove(“key”);
JeeConf 2011 — Kiev 36

139. Local transaction
 Cheap!
 Requires you to do the demarcation
transactionController
= cacheManager.getTransactionController();
transactionController.begin();
cache1 = cacheManager.getEhcache("txCache1");
cache1.put(new Element(1, putValue));
cache2 = cacheManager.getEhcache("txCache2");
cache2.remove(“key”);
transactionController.rollback();
JeeConf 2011 — Kiev 36

140. XA Caches
JeeConf 2011 — Kiev 37

141. XA Caches
 What for ?
– Synchronicity of data between
Ehcache & other XA resources is guaranteed
JeeConf 2011 — Kiev 37

142. XA Caches
 What for ?
– Synchronicity of data between
Ehcache & other XA resources is guaranteed
 How ?
– Two phase commit
JeeConf 2011 — Kiev 37

143. XA Caches
 What for ?
– Synchronicity of data between
Ehcache & other XA resources is guaranteed
 How ?
– Two phase commit
 Java Transaction API to the rescue !
– JSR907 / Direct port of the X/Open XA standard
– JTA is about reading and writing transactionally into multiple
resources:
• databases JMS servers,
• caches,
• or whatever is used to store or transport data
– The transaction manager manages and drives XA resources
JeeConf 2011 — Kiev 37

144. XA Caches
JeeConf 2011 — Kiev 38

145. XA Caches
 READ_COMMITED isolation level
JeeConf 2011 — Kiev 38

146. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
JeeConf 2011 — Kiev 38

147. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
– Figure the TransactionManager out
JeeConf 2011 — Kiev 38

148. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
– Figure the TransactionManager out
– Enlist in the Transaction automagically
JeeConf 2011 — Kiev 38

149. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
– Figure the TransactionManager out
– Enlist in the Transaction automagically
– Only be accessible within an inflight Transaction
JeeConf 2011 — Kiev 38

150. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
– Figure the TransactionManager out
– Enlist in the Transaction automagically
– Only be accessible within an inflight Transaction
 XA
JeeConf 2011 — Kiev 38

151. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
– Figure the TransactionManager out
– Enlist in the Transaction automagically
– Only be accessible within an inflight Transaction
 XA
– Will synchronize on the inflight XA Transaction
JeeConf 2011 — Kiev 38

152. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
– Figure the TransactionManager out
– Enlist in the Transaction automagically
– Only be accessible within an inflight Transaction
 XA
– Will synchronize on the inflight XA Transaction
 XA_STRICT
JeeConf 2011 — Kiev 38

153. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
– Figure the TransactionManager out
– Enlist in the Transaction automagically
– Only be accessible within an inflight Transaction
 XA
– Will synchronize on the inflight XA Transaction
 XA_STRICT
– Will register a full blown XAResource with the TX
JeeConf 2011 — Kiev 38

154. XA Caches
 READ_COMMITED isolation level
 Transactional Caches will :
– Figure the TransactionManager out
– Enlist in the Transaction automagically
– Only be accessible within an inflight Transaction
 XA
– Will synchronize on the inflight XA Transaction
 XA_STRICT
– Will register a full blown XAResource with the TX
• Including support for recovery
JeeConf 2011 — Kiev 38

155. Sometimes,... you want less consistency
JeeConf 2011 — Kiev 39

156. Sometimes,... you want less consistency
 When clustered, consistency comes at prices
– That you might not always want to pay
JeeConf 2011 — Kiev 39

157. Sometimes,... you want less consistency
 When clustered, consistency comes at prices
– That you might not always want to pay
 Introducing eventual consistency
– No lock involved
– Client sends
• updates asynchronously
• send as batches to the server
– Other client knowing about the value for a key,
gets the updates pushed to by the server
• Might see stale values for some milliseconds from local cache
JeeConf 2011 — Kiev 39

158. Consistency types for clustered caches
JeeConf 2011 — Kiev 40

159. Consistency types for clustered caches
 Also configurable per cache
– Strong(JMM)
– Eventual consistency
• Will use the local cached value
JeeConf 2011 — Kiev 40

160. Consistency types for clustered caches
 Also configurable per cache
– Strong(JMM)
– Eventual consistency
• Will use the local cached value
 Non-stop caches
– Lets you configure
• Timeout on caches
• Timeout behavior
– noop
– exception
– local read
JeeConf 2011 — Kiev 40

161. Consistency types for clustered caches
 Also configurable per cache
– Strong(JMM)
– Eventual consistency
• Will use the local cached value
 Non-stop caches
– Lets you configure
• Timeout on caches
• Timeout behavior
– noop
– exception
– local read
 Rejoin
JeeConf 2011 — Kiev 40

162. Where’s my data ?!
… when key lookup isn’t enough

163. Key / Value
JeeConf 2011 — Kiev 42

164. Key / Value
 Sometimes retrieving values only based on a key
isn’t enough, because
– You don’t know the key
– The key / value paradigm simply doesn’t apply
JeeConf 2011 — Kiev 42

165. Key / Value
 Sometimes retrieving values only based on a key
isn’t enough, because
– You don’t know the key
– The key / value paradigm simply doesn’t apply
 Giventhe amount of data now storable
Search was just the natural next step...
JeeConf 2011 — Kiev 42

166. Introducing Ehcache Search
JeeConf 2011 — Kiev 43

167. Introducing Ehcache Search
 Ehcache Search is a querying capability
built into the core OSS Ehcache API
JeeConf 2011 — Kiev 43

168. Introducing Ehcache Search
 Ehcache Search is a querying capability
built into the core OSS Ehcache API
 Provides fast,
flexible access to every aspect of your in-memory data
JeeConf 2011 — Kiev 43

169. Introducing Ehcache Search
 Ehcache Search is a querying capability
built into the core OSS Ehcache API
 Provides fast,
flexible access to every aspect of your in-memory data
 Offloads queries from the database
reducing the DB’s role as a bottleneck
– Or adds search-ability to data that wasn’t before, like WS
JeeConf 2011 — Kiev 43

170. Introducing Ehcache Search
 Ehcache Search is a querying capability
built into the core OSS Ehcache API
 Provides fast,
flexible access to every aspect of your in-memory data
 Offloads queries from the database
reducing the DB’s role as a bottleneck
– Or adds search-ability to data that wasn’t before, like WS
 Improves application performance/latency
JeeConf 2011 — Kiev 43

171. Introducing Ehcache Search
 Ehcache Search is a querying capability
built into the core OSS Ehcache API
 Provides fast,
flexible access to every aspect of your in-memory data
 Offloads queries from the database
reducing the DB’s role as a bottleneck
– Or adds search-ability to data that wasn’t before, like WS
 Improves application performance/latency
 Works efficiently when standalone
JeeConf 2011 — Kiev 43

172. Introducing Ehcache Search
 Ehcache Search is a querying capability
built into the core OSS Ehcache API
 Provides fast,
flexible access to every aspect of your in-memory data
 Offloads queries from the database
reducing the DB’s role as a bottleneck
– Or adds search-ability to data that wasn’t before, like WS
 Improves application performance/latency
 Works efficiently when standalone
 Scales out linearly with your data when distributed
(O(Log n)/Server Count) without code changes
JeeConf 2011 — Kiev 43

173. Two key concepts in search
JeeConf 2011 — Kiev 44

174. Two key concepts in search
 Attributes
– What can be searched
JeeConf 2011 — Kiev 44

175. Two key concepts in search
 Attributes
– What can be searched
 Queries
– FluentObject Oriented interface
used for searching the cache
leveraging the defined Attributes
JeeConf 2011 — Kiev 44

176. Attributes
JeeConf 2011 — Kiev 45

177. Attributes
 Definition Types
JeeConf 2011 — Kiev 45

178. Attributes
 Definition Types
– Beanattributes
Bean style properties on the key or value
JeeConf 2011 — Kiev 45

179. Attributes
 Definition Types
– Bean attributes
Bean style properties on the key or value
– Expressions
Method calls and/or field accesses
JeeConf 2011 — Kiev 45

180. Attributes
 Definition Types
– Bean attributes
Bean style properties on the key or value
– Expressions
Method calls and/or field accesses
– Custom Extractors
A user defined class
that can extract what ever you need for searching
JeeConf 2011 — Kiev 45

181. Attributes
 Definition Types
– Bean attributes
Bean style properties on the key or value
– Expressions
Method calls and/or field accesses
– Custom Extractors
A user defined class
that can extract what ever you need for searching
 Definition Styles
JeeConf 2011 — Kiev 45

182. Attributes
 Definition Types
– Bean attributes
Bean style properties on the key or value
– Expressions
Method calls and/or field accesses
– Custom Extractors
A user defined class
that can extract what ever you need for searching
 Definition Styles
– XML
JeeConf 2011 — Kiev 45

183. Attributes
 Definition Types
– Bean attributes
Bean style properties on the key or value
– Expressions
Method calls and/or field accesses
– Custom Extractors
A user defined class
that can extract what ever you need for searching
 Definition Styles
– XML
– Code
JeeConf 2011 — Kiev 45

184. Attribute definition
 XML
<searchable>
<!-- Bean style spec -->
<searchAttribute name="age" />
<!-- Expression style spec -->
<searchAttribute name="gender"
expression="value.getGender()" />
<!-- Custom Extractor style spec -->
<searchAttribute
name="name"
class="com.company.NameAttributeExtractor" />
</searchable>
JeeConf 2011 — Kiev 46

185. Queries
JeeConf 2011 — Kiev 47

186. Queries
 A fluent object oriented interface
based on the defined Attributes.
JeeConf 2011 — Kiev 47

187. Queries
 A fluent object oriented interface
based on the defined Attributes.
 Aggregate
– Sum, Average, Min, Max, Count
JeeConf 2011 — Kiev 47

188. Queries
 A fluent object oriented interface
based on the defined Attributes.
 Aggregate
– Sum, Average, Min, Max, Count
 Match
– ilike, eq, between, gt, lt, between etc
JeeConf 2011 — Kiev 47

189. Queries
 A fluent object oriented interface
based on the defined Attributes.
 Aggregate
– Sum, Average, Min, Max, Count
 Match
– ilike, eq, between, gt, lt, between etc
 Logical Operators
– and, or, not
JeeConf 2011 — Kiev 47

190. Queries
 A fluent object oriented interface
based on the defined Attributes.
 Aggregate
– Sum, Average, Min, Max, Count
 Match
– ilike, eq, between, gt, lt, between etc
 Logical Operators
– and, or, not
 Result Set Control
– Ascending vs descending, max object counts,
include keys/values, ranges
JeeConf 2011 — Kiev 47

191. When moving data is not a good idea!
Sending the work to data

192. Introducing Quartz Scheduler
JeeConf 2011 — Kiev 49

193. Introducing Quartz Scheduler
 Lets you schedule asynchronous jobs
JeeConf 2011 — Kiev 49

194. Introducing Quartz Scheduler
 Lets you schedule asynchronous jobs
 De facto scheduler for the Java Platform
JeeConf 2011 — Kiev 49

195. Introducing Quartz Scheduler
 Lets you schedule asynchronous jobs
 De facto scheduler for the Java Platform
 Easily clusterable using Terracotta
– Share scheduler across Cluster
– Persistent storage for your jobs
JeeConf 2011 — Kiev 49

196. One simple API
JeeConf 2011 — Kiev

197. One simple API
 Job
– Actual Job implementation
– Defines what to execute
– Think the script for a cron entry
JeeConf 2011 — Kiev

198. One simple API
 Job
– Actual Job implementation
– Defines what to execute
– Think the script for a cron entry
public class MyJob implements Job {
public void execute(final JobExecutionContext context)
throws JobExecutionException {
// Do the actual work
}
}
JeeConf 2011 — Kiev

199. One simple API
 Job
– Actual Job implementation
– Defines what to execute
– Think the script for a cron entry
 Triggers
– Fire the Job for execution
– Defines when to execute
– Think the actual cron expression
JeeConf 2011 — Kiev

200. One simple API
 Job
– Actual Job implementation
– Defines what to execute
– Think the script for a cron entry
 Triggers
– Fire the Job for execution
– Defines when to execute
– Think the actual cron expression
 Single API
– To schedule Jobs & Triggers
– That actually executes these Jobs
JeeConf 2011 — Kiev

201. Quartz Where & Ehcache
JVM
JVM
JVM
SchedulerThread
JVM
JeeConf 2011 — Kiev

202. Quartz Where & Ehcache
JVM
JVM
JVM
SchedulerThread
scheduler.scheduleJob(job, trigger);
JVM
JeeConf 2011 — Kiev

203. Quartz Where & Ehcache
JVM
JVM
JVM
SchedulerThread
JVM
JeeConf 2011 — Kiev

204. Quartz Where & Ehcache
JVM
JVM
L1
JVM
SchedulerThread
L1
JVM
L1
JeeConf 2011 — Kiev

205. Quartz Where & Ehcache
JVM
JVM
L1
JVM
SchedulerThread
L1
JVM
L1
JeeConf 2011 — Kiev

206. Quartz Where & Ehcache
JVM
JVM
L1
JVM
SchedulerThread
L1
JVM
L1
JeeConf 2011 — Kiev

207. I know… it’s late now!
So, in summary

208. Summary
JeeConf 2011 — Kiev 53

209. Summary
 Ehcache
JeeConf 2011 — Kiev 53

210. Summary
 Ehcache
– Scales your system of record today
JeeConf 2011 — Kiev 53

211. Summary
 Ehcache
– Scales your system of record today
– Easily!
JeeConf 2011 — Kiev 53

212. Summary
 Ehcache
– Scales your system of record today
– Easily!
 Terracotta
JeeConf 2011 — Kiev 53

213. Summary
 Ehcache
– Scales your system of record today
– Easily!
 Terracotta
– Scales your cache when it needs it
JeeConf 2011 — Kiev 53

214. Summary
 Ehcache
– Scales your system of record today
– Easily!
 Terracotta
– Scales your cache when it needs it
– Whether
JeeConf 2011 — Kiev 53

215. Summary
 Ehcache
– Scales your system of record today
– Easily!
 Terracotta
– Scales your cache when it needs it
– Whether
• In terms of data sizes
JeeConf 2011 — Kiev 53

216. Summary
 Ehcache
– Scales your system of record today
– Easily!
 Terracotta
– Scales your cache when it needs it
– Whether
• In terms of data sizes
• Processing power
JeeConf 2011 — Kiev 53

217. Summary
 Ehcache
– Scales your system of record today
– Easily!
 Terracotta
– Scales your cache when it needs it
– Whether
• In terms of data sizes
• Processing power
• Redundancy
JeeConf 2011 — Kiev 53

218. Summary
 Ehcache
– Scales your system of record today
– Easily!
 Terracotta
– Scales your cache when it needs it
– Whether
• In terms of data sizes
• Processing power
• Redundancy
• Persistency
JeeConf 2011 — Kiev 53

219. Summary
 Ehcache
– Scales your system of record today
– Easily!
 Terracotta
– Scales your cache when it needs it
– Whether
• In terms of data sizes
• Processing power
• Redundancy
• Persistency
 All these features available
with a couple lines of configuration only
JeeConf 2011 — Kiev 53

220. ehcache | ehcache.org
quartz | quartz-scheduler.org
terracotta | terracotta.org
Thank you !

221. ehcache | ehcache.org
quartz | quartz-scheduler.org
terracotta | terracotta.org
twitter | @alexsnaps
email | alexsnaps@terracotta.org
blog | www.codespot.net

222. ehcache | ehcache.org
quartz | quartz-scheduler.org
terracotta | terracotta.org
twitter | @alexsnaps
email | alexsnaps@terracotta.org
blog | www.codespot.net