Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Alex Snaps JEEConf Presentation

1,574 views

Published on

Published in: Technology, Education

Alex Snaps JEEConf Presentation

  1. 1. Scaling up & out withEhcache and TerracottaAlex SnapsSenior Software Engineer — Terracotta, Inc.
  2. 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. 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. 4. Who’s who ?… on Ehcache, Terracotta and… last & least, me.
  5. 5. Ehcache JeeConf 2011 — Kiev 5
  6. 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. 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. 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. 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. 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. 11. Terracotta JeeConf 2011 — Kiev 6
  12. 12. Terracotta Founded 2003 in San Francisco, CA JeeConf 2011 — Kiev 6
  13. 13. Terracotta Founded 2003 in San Francisco, CA Present in India, Europe and pretty much all over the globe! JeeConf 2011 — Kiev 6
  14. 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. 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. 16. About me … JeeConf 2011 — Kiev 7
  17. 17. About me … Senior Software Engineer at Terracotta – Working on Ehcache & Terracotta integration, – Quartz Enterprise Scheduler, – Terracotta toolkit JeeConf 2011 — Kiev 7
  18. 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. 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. 20. Now to the fun part!Data access patterns revisited
  21. 21. Big Data ? JeeConf 2011 — Kiev 9
  22. 22. Big Data ? Whats Big Data for you? JeeConf 2011 — Kiev 9
  23. 23. Big Data ? Whats Big Data for you? Not a question of quantity. JeeConf 2011 — Kiev 9
  24. 24. Big Data ? Whats Big Data for you? Not a question of quantity. – Gigabytes? JeeConf 2011 — Kiev 9
  25. 25. Big Data ? Whats Big Data for you? Not a question of quantity. – Gigabytes? – Terabytes? JeeConf 2011 — Kiev 9
  26. 26. Big Data ? Whats Big Data for you? Not a question of quantity. – Gigabytes? – Terabytes? – Petabytes? JeeConf 2011 — Kiev 9
  27. 27. Big Data ? Whats Big Data for you? Not a question of quantity. – Gigabytes? – Terabytes? – Petabytes? Its all about supporting your business growth. JeeConf 2011 — Kiev 9
  28. 28. Big Data ? Whats Big Data for you? Not a question of quantity. – Gigabytes? – Terabytes? – Petabytes? Its all about supporting your business growth. – Growth in terms of schema evolution. JeeConf 2011 — Kiev 9
  29. 29. Big Data ? Whats Big Data for you? Not a question of quantity. – Gigabytes? – Terabytes? – Petabytes? Its all about supporting your business growth. – Growth in terms of schema evolution. – Growth in terms of data storage. JeeConf 2011 — Kiev 9
  30. 30. Big Data ? Whats Big Data for you? Not a question of quantity. – Gigabytes? – Terabytes? – Petabytes? Its 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. 31. Big Data ? Whats Big Data for you? Not a question of quantity. – Gigabytes? – Terabytes? – Petabytes? Its 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. 32. Where’s all that data ?Relational databases & friends
  33. 33. How do you access your database ? JeeConf 2011 — Kiev 11
  34. 34. How do you access your database ? JeeConf 2011 — Kiev 11
  35. 35. Caching JeeConf 2011 — Kiev 12
  36. 36. Caching  If going to the database is so expensive... ... we should just avoid it! JeeConf 2011 — Kiev 12
  37. 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. 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. 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. 40. Cache in front of the database JeeConf 2011 — Kiev 13
  41. 41. Cache in front of the database RDBMS READ Helps scale your read operations Cache READ PowerBook G4 JeeConf 2011 — Kiev 13
  42. 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. 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. 44. Cache in front of the database JeeConf 2011 — Kiev 15
  45. 45. Cache in front of the database Helps scale your read operations JeeConf 2011 — Kiev 15
  46. 46. Cache in front of the database Helps scale your read operations – Writes go directly to the database JeeConf 2011 — Kiev 15
  47. 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. 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. 49. Write-through RDBMS Cache Application code JeeConf 2011 — Kiev
  50. 50. Write-through RDBMS Cache Application code JeeConf 2011 — Kiev
  51. 51. Write-through RDBMS Cache Application code JeeConf 2011 — Kiev
  52. 52. Write-through RDBMS Cache Application code JeeConf 2011 — Kiev
  53. 53. Write-behind JeeConf 2011 — Kiev 17
  54. 54. Write-behind Rather than write changes directly to the slowest participant JeeConf 2011 — Kiev 17
  55. 55. Write-behind Rather than write changes directly to the slowest participant – Write to faster durable store (persistent queue) JeeConf 2011 — Kiev 17
  56. 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. 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. 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. 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. 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. 61. Write-behind RDBMS Cache Application code JeeConf 2011 — Kiev
  62. 62. Write-behind RDBMS Cache Application code JeeConf 2011 — Kiev
  63. 63. Write-behind RDBMS Cache Writer Application code JeeConf 2011 — Kiev
  64. 64. Write-behind RDBMS Cache Writer Application code JeeConf 2011 — Kiev
  65. 65. Write-behind RDBMS Cache Writer Application code JeeConf 2011 — Kiev
  66. 66. Write-behind RDBMS Cache Writer Application code JeeConf 2011 — Kiev
  67. 67. Write-behind RDBMS Cache Writer Application code JeeConf 2011 — Kiev
  68. 68. Write-behind RDBMS Cache Writer Application code JeeConf 2011 — Kiev
  69. 69. Write-behind RDBMS Cache Writer Application code JeeConf 2011 — Kiev
  70. 70. Write-behind RDBMS Writer Cache Writer Application code JeeConf 2011 — Kiev
  71. 71. Write-behind RDBMS Writer Cache Writer Application code JeeConf 2011 — Kiev
  72. 72. Write-behind JeeConf 2011 — Kiev 19
  73. 73. Write-behind Very configurable JeeConf 2011 — Kiev 19
  74. 74. Write-behind Very configurable – Batching & Coalescing JeeConf 2011 — Kiev 19
  75. 75. Write-behind Very configurable – Batching & Coalescing – Maximum delay between each write JeeConf 2011 — Kiev 19
  76. 76. Write-behind Very configurable – Batching & Coalescing – Maximum delay between each write – Limit the writes per seconds JeeConf 2011 — Kiev 19
  77. 77. Write-behind Very configurable – Batching & Coalescing – Maximum delay between each write – Limit the writes per seconds – Retry configuration JeeConf 2011 — Kiev 19
  78. 78. Write-behind Very configurable – Batching & Coalescing – Maximum delay between each write – Limit the writes per seconds – Retry configuration JeeConf 2011 — Kiev 19
  79. 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. 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. 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. 82. Scaling the database JeeConf 2011 — Kiev 20
  83. 83. Scaling the database JeeConf 2011 — Kiev 20
  84. 84. Scaling the cache JeeConf 2011 — Kiev 21
  85. 85. Scaling the cache JeeConf 2011 — Kiev 21
  86. 86. BigMemory JeeConf 2011 — Kiev 22
  87. 87. BigMemory OffHeap storage – But in process memory JeeConf 2011 — Kiev 22
  88. 88. BigMemory OffHeap storage – But in process memory Uses DirectByteBuffer JeeConf 2011 — Kiev 22
  89. 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. 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. 91. Large data on a single VM JeeConf 2011 — Kiev 23
  92. 92. Distributed Caching JeeConf 2011 — Kiev 24
  93. 93. Distributed Caching  What if data isnt perfectly partitioned ? JeeConf 2011 — Kiev 24
  94. 94. Distributed Caching  What if data isnt perfectly partitioned ?  How do we keep this all in sync ? JeeConf 2011 — Kiev 24
  95. 95. Distributed Caching  What if data isnt perfectly partitioned ?  How do we keep this all in sync ?  Peer-to-peer ? JeeConf 2011 — Kiev 24
  96. 96. Distributed Caching JeeConf 2011 — Kiev 25
  97. 97. Distributed Caching  Cached data remains close to the processing unit JeeConf 2011 — Kiev 25
  98. 98. Distributed Caching  Cached data remains close to the processing unit  Central unit orchestrates it all JeeConf 2011 — Kiev 25
  99. 99. Distributed Caching JeeConf 2011 — Kiev 26
  100. 100. Distributed Caching JeeConf 2011 — Kiev 27
  101. 101. Distributed Caching JeeConf 2011 — Kiev 28
  102. 102. DCV2 JeeConf 2011 — Kiev 29
  103. 103. DCV2 Simple storage change in the cache config – <terracotta storageStrategy=”DCV2” /> JeeConf 2011 — Kiev 29
  104. 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. 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. 106. Consistency considerationsFrom Happens-Before to ACID to 2PC and… back!
  107. 107. The ACID guarantees JeeConf 2011 — Kiev 31
  108. 108. The ACID guarantees Let people easily reason about the problem JeeConf 2011 — Kiev 31
  109. 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. 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. 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. 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. 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. 114. ... and that’s what you get JeeConf 2011 — Kiev 32
  115. 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. 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. 117. Basic tools JeeConf 2011 — Kiev 33
  118. 118. Basic tools Blocking & SelfPopulatingCache constructs – Will not let multiple threads populate the cache with the same key JeeConf 2011 — Kiev 33
  119. 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. 120. Atomic Operations JeeConf 2011 — Kiev 34
  121. 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. 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. 123. Transactional caches JeeConf 2011 — Kiev 35
  124. 124. Transactional caches When you need rollback! JeeConf 2011 — Kiev 35
  125. 125. Transactional caches Whenyou need rollback! Comes in three flavors: – local – xa – xa_strict JeeConf 2011 — Kiev 35
  126. 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. 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. 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. 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. 130. Local transaction JeeConf 2011 — Kiev 36
  131. 131. Local transaction Cheap! JeeConf 2011 — Kiev 36
  132. 132. Local transaction Cheap! Requires you to do the demarcation JeeConf 2011 — Kiev 36
  133. 133. Local transaction Cheap! Requires you to do the demarcation transactionController = cacheManager.getTransactionController(); JeeConf 2011 — Kiev 36
  134. 134. Local transaction Cheap! Requires you to do the demarcation transactionController = cacheManager.getTransactionController(); transactionController.begin(); JeeConf 2011 — Kiev 36
  135. 135. Local transaction Cheap! Requires you to do the demarcation transactionController = cacheManager.getTransactionController(); transactionController.begin(); cache1 = cacheManager.getEhcache("txCache1"); JeeConf 2011 — Kiev 36
  136. 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. 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. 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. 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. 140. XA Caches JeeConf 2011 — Kiev 37
  141. 141. XA Caches What for ? – Synchronicity of data between Ehcache & other XA resources is guaranteed JeeConf 2011 — Kiev 37
  142. 142. XA Caches What for ? – Synchronicity of data between Ehcache & other XA resources is guaranteed How ? – Two phase commit JeeConf 2011 — Kiev 37
  143. 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. 144. XA Caches JeeConf 2011 — Kiev 38
  145. 145. XA Caches READ_COMMITED isolation level JeeConf 2011 — Kiev 38
  146. 146. XA Caches READ_COMMITED isolation level Transactional Caches will : JeeConf 2011 — Kiev 38
  147. 147. XA Caches READ_COMMITED isolation level Transactional Caches will : – Figure the TransactionManager out JeeConf 2011 — Kiev 38
  148. 148. XA Caches READ_COMMITED isolation level Transactional Caches will : – Figure the TransactionManager out – Enlist in the Transaction automagically JeeConf 2011 — Kiev 38
  149. 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. 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. 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. 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. 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. 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. 155. Sometimes,... you want less consistency JeeConf 2011 — Kiev 39
  156. 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. 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. 158. Consistency types for clustered caches JeeConf 2011 — Kiev 40
  159. 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. 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. 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. 162. Where’s my data ?!… when key lookup isn’t enough
  163. 163. Key / Value JeeConf 2011 — Kiev 42
  164. 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. 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. 166. Introducing Ehcache Search JeeConf 2011 — Kiev 43
  167. 167. Introducing Ehcache Search Ehcache Search is a querying capability built into the core OSS Ehcache API JeeConf 2011 — Kiev 43
  168. 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. 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. 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. 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. 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. 173. Two key concepts in search JeeConf 2011 — Kiev 44
  174. 174. Two key concepts in search Attributes – What can be searched JeeConf 2011 — Kiev 44
  175. 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. 176. Attributes JeeConf 2011 — Kiev 45
  177. 177. Attributes Definition Types JeeConf 2011 — Kiev 45
  178. 178. Attributes Definition Types – Beanattributes Bean style properties on the key or value JeeConf 2011 — Kiev 45
  179. 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. 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. 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. 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. 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. 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. 185. Queries JeeConf 2011 — Kiev 47
  186. 186. Queries A fluent object oriented interface based on the defined Attributes. JeeConf 2011 — Kiev 47
  187. 187. Queries A fluent object oriented interface based on the defined Attributes. Aggregate – Sum, Average, Min, Max, Count JeeConf 2011 — Kiev 47
  188. 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. 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. 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. 191. When moving data is not a good idea!Sending the work to data
  192. 192. Introducing Quartz Scheduler JeeConf 2011 — Kiev 49
  193. 193. Introducing Quartz Scheduler Lets you schedule asynchronous jobs JeeConf 2011 — Kiev 49
  194. 194. Introducing Quartz Scheduler Lets you schedule asynchronous jobs De facto scheduler for the Java Platform JeeConf 2011 — Kiev 49
  195. 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. 196. One simple API JeeConf 2011 — Kiev
  197. 197. One simple API Job – Actual Job implementation – Defines what to execute – Think the script for a cron entry JeeConf 2011 — Kiev
  198. 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. 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. 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. 201. Quartz Where & Ehcache JVM JVM JVM SchedulerThread JVM JeeConf 2011 — Kiev
  202. 202. Quartz Where & Ehcache JVM JVM JVM SchedulerThread scheduler.scheduleJob(job, trigger); JVM JeeConf 2011 — Kiev
  203. 203. Quartz Where & Ehcache JVM JVM JVM SchedulerThread JVM JeeConf 2011 — Kiev
  204. 204. Quartz Where & Ehcache JVM JVM L1 JVM SchedulerThread L1 JVM L1 JeeConf 2011 — Kiev
  205. 205. Quartz Where & Ehcache JVM JVM L1 JVM SchedulerThread L1 JVM L1 JeeConf 2011 — Kiev
  206. 206. Quartz Where & Ehcache JVM JVM L1 JVM SchedulerThread L1 JVM L1 JeeConf 2011 — Kiev
  207. 207. I know… it’s late now!So, in summary
  208. 208. Summary JeeConf 2011 — Kiev 53
  209. 209. Summary Ehcache JeeConf 2011 — Kiev 53
  210. 210. Summary Ehcache – Scales your system of record today JeeConf 2011 — Kiev 53
  211. 211. Summary Ehcache – Scales your system of record today – Easily! JeeConf 2011 — Kiev 53
  212. 212. Summary Ehcache – Scales your system of record today – Easily! Terracotta JeeConf 2011 — Kiev 53
  213. 213. Summary Ehcache – Scales your system of record today – Easily! Terracotta – Scales your cache when it needs it JeeConf 2011 — Kiev 53
  214. 214. Summary Ehcache – Scales your system of record today – Easily! Terracotta – Scales your cache when it needs it – Whether JeeConf 2011 — Kiev 53
  215. 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. 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. 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. 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. 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. 220. ehcache | ehcache.org quartz | quartz-scheduler.org terracotta | terracotta.orgThank you !
  221. 221. ehcache | ehcache.org quartz | quartz-scheduler.orgterracotta | terracotta.org twitter | @alexsnaps email | alexsnaps@terracotta.org blog | www.codespot.net
  222. 222. ehcache | ehcache.org quartz | quartz-scheduler.orgterracotta | terracotta.org twitter | @alexsnaps email | alexsnaps@terracotta.org blog | www.codespot.net

×