Successfully reported this slideshow.
Your SlideShare is downloading. ×

Alex Snaps JEEConf Presentation

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Alex Snaps JEEConf Presentation

  1. 1. Scaling up & out with Ehcache and Terracotta Alex Snaps Senior 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 ?  What's Big Data for you? JeeConf 2011 — Kiev 9
  23. 23. Big Data ?  What's Big Data for you?  Not a question of quantity. JeeConf 2011 — Kiev 9
  24. 24. Big Data ?  What's Big Data for you?  Not a question of quantity. – Gigabytes? JeeConf 2011 — Kiev 9
  25. 25. Big Data ?  What's Big Data for you?  Not a question of quantity. – Gigabytes? – Terabytes? JeeConf 2011 — Kiev 9
  26. 26. Big Data ?  What's Big Data for you?  Not a question of quantity. – Gigabytes? – Terabytes? – Petabytes? JeeConf 2011 — Kiev 9
  27. 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. 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. 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. 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. 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. 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 isn't perfectly partitioned ? JeeConf 2011 — Kiev 24
  94. 94. Distributed Caching  What if data isn't perfectly partitioned ?  How do we keep this all in sync ? JeeConf 2011 — Kiev 24
  95. 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. 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 considerations From 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.org Thank you !
  221. 221. ehcache | ehcache.org quartz | quartz-scheduler.org terracotta | terracotta.org twitter | @alexsnaps email | alexsnaps@terracotta.org blog | www.codespot.net
  222. 222. ehcache | ehcache.org quartz | quartz-scheduler.org terracotta | terracotta.org twitter | @alexsnaps email | alexsnaps@terracotta.org blog | www.codespot.net

Editor's Notes

  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • ImmutableValueElementCopyStrategy\n copies the element, not its value\n
  • ImmutableValueElementCopyStrategy\n copies the element, not its value\n
  • ImmutableValueElementCopyStrategy\n copies the element, not its value\n
  • ImmutableValueElementCopyStrategy\n copies the element, not its value\n
  • ImmutableValueElementCopyStrategy\n copies the element, not its value\n
  • ImmutableValueElementCopyStrategy\n copies the element, not its value\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

×