Smith Scaling Java Applications With Coherence


Published on

Presentación a cargo de Shaun Smith en el marco del Updateo8 organizado por Snoop Consulting

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Smith Scaling Java Applications With Coherence

  1. 1. Shaun Smith Scaling Java Applications with Oracle Coherence Leveraging the Power of Data Grids
  2. 2. Speaker Product Manager for Oracle TopLink Working with object-relational and object-XML mapping technology for over 10 years. Involved with Coherence/TopLink Integration Eclipse Persistence Services Project (EclipseLink) Ecosystem Development Lead Eclipse Dali JPA Tools Project Co-Lead Eclipse Teneo Project Committer Nº2
  3. 3. Agenda Scaling Challenges for Java Applications Coherence Data Grid Scaling with Coherence Nº3
  4. 4. Scaling Challenges Nº4
  5. 5. Types of Application State Request State Request/Response HTTP/RMI Conversational (Transient) State Spans multiple requests Scoped to a single “user” HTTP Sessions/Stateless Session Beans Persistent (Durable) State Permanent durable storage Relational Databases Nº5
  6. 6. Request State Characteristics Short lived Life span measured in milliseconds to seconds Immutable and scoped to a single user Almost no way to corrupt state, easy to avoid losing state “Stateless” applications are very easy to scale Few applications that work with databases are truly “stateless” Nº6
  7. 7. Conversational State Characteristics Longer lived Life span measured in seconds to minutes Mutable and scoped to a single user Not quite single writer, may have to deal with simultaneous requests from a user Portlets Frames Multiple clicks Load balancing issues: failover/failback/rebalancing Often recoverable Worst case, by restarting the session Nº7
  8. 8. Persistent State Characteristics Long lived Life span often measured in years Often have regulatory requirements Mutable and globally shared Possible interaction and contention from all users Concurrency and data consistency are hard to combine Nº8
  9. 9. Scaling Characteristics Request State Easiest to scale Add more hardware to handle extra HTTP/RMI connections Conversational State Sticky Sessions without session replication Scales well, but data loss if node fails Session replication Works well for small - medium applications Cluster may be incoherent upon high load Persistent State Most difficult to scale Absolute requirement for data consistency makes scaling difficult (but possible) Nº9
  10. 10. Typical Web Application HTTP Sessions Service Interfaces Data Store Domain Objects Data Access Nº10
  11. 11. Typical Web Application Applications that cannot loose session data may have scaling challenges HTTP Sessions with session state Service Interfaces Data Store Domain Objects Data Access Nº11
  12. 12. Typical Web Application Applications that cannot loose session data may have scaling challenges HTTP Sessions with session state Service Interfaces Data Store Domain Objects Scaling the application tier may Data Access cause the database to be a scalability bottleneck Nº12
  13. 13. Data Grid Nº13
  14. 14. Introducing the Data Grid Data Management & Clustering Solution Live, transactional data in-memory Automatic partitioning of application data Single holistic view of application data Ability to search, analyze, process information Nº14
  15. 15. Oracle Coherence Data Grid Communication via unicast UDP Specialized protocol maintains cluster membership and data partitioning No single point of failure True peer to peer system Nº15
  16. 16. Partitioned Topology: Data Access Data spread and backed up across nodes Transparent to developer Members have access to all data All data locations are known - no lookups & no registry Nº16
  17. 17. Partitioned Topology: Data Update Synchronous Update Avoids potential data loss & corruption Predictable performance Backup partitions are partitioned away from primaries for resilience No engineering requirement to setup primaries or backups Nº17
  18. 18. Partitioned Topology: Recovery Membership changes (members added or removed) Other members, in parallel, recover/repartition No in-flight operations lost Some latency due to higher priority of recovery Nº18
  19. 19. Using Coherence Nº19
  20. 20. Cache Interfaces Map, CacheMap, Traditional Map interface, ConcurrentMap also includes concurrency control (lock, unlock) ObservableMap Real-time events based on filters for insert, update, delete QueryMap Allows for query-based access to cache entries, which can be executed in parallel across the grid InvocableMap Execute processors against cache entries in the nodes responsible for storage (also can be executed in parallel Nº20
  21. 21. Traditional Map Interface Implements Map interface Drop in replacement. Full concurrency control. Multi-threaded. Scalable and resilient! get, put, putAll, size, clear, lock, unlock… Implements JCache interface Extensive support for a multitude of expiration policies, including none! More than “just a Cache”. More than “just a Map” Nº21
  22. 22. Clustered Hello World… public static void main(String[] args) throws IOException { NamedCache nc = CacheFactory.getCache(“test”); nc.put(“message”, “Hello World”); System.out.println(nc.get(“message”));; } Joins / Establishes a cluster Places an Entry (key, value) into the Cache “test” (notice no configuration) Retrieves the Entry from the Cache. Displays it. “read” at the end to keep the application (and Cluster) from terminating. Nº22
  23. 23. Clustered Hello World… public static void main(String[] args) throws IOException { NamedCache nc = CacheFactory.getCache(“test”); System.out.println(nc.get(“message”)); } Joins / Establishes a cluster Retrieves the Entry from the Cache. Displays it Start as many applications as you like… they all cluster the are able to share the values in the cache Nº23
  24. 24. Demo Nº24
  25. 25. Observable Interface Real-time filterable (bean) events for entry insert, update, delete Filters applied in parallel (in the Grid) Filters completely extensible A large range of filters out-of-the-box: All, Always, And, Any, Array, Between, Class, Comparison, ContainsAll, ContainsAny, Contains, Equals, GreaterEquals, Greater, In, InKeySet, IsNotNull, IsNull, LessEquals, Less, Like, Limit, Never, NotEquals, Not, Or, Present, Xor… Events may be synchronous – trades.addMapListener( new StockEventFilter(“ORCL”), new MyMapListener(…)); Nº25
  26. 26. Observable Interface Nº26
  27. 27. QueryMap Interface Find Keys or Values that satisfy a Filter. entrySet(…), keySet(…) Define indexes (on-the-fly) to extract and index any part of an Entry Executed in Parallel Create Continuous View of entries based on a Filter with real-time events dispatch Perfect for client applications “watching” data Nº27
  28. 28. Features : QueryMap Interface Nº28
  29. 29. Demo Nº29
  30. 30. Features : InvocableMap Interface Execute processors against an Entry, a Collection or a Filter Executions occur in parallel (aka: Grid-style) No “workers” to manage! Processors may return any value – trades.invokeAll( new EqualsFilter(“getSecurity”,“ORCL”), new StockSplit(2.0)); Aggregate Entries based on a Filter – positions.aggregate( new EqualsFilter(“getSecurity”,“ORCL”), new SumFilter(“amount”)); Nº30
  31. 31. Features : InvocableMap Interface Nº31
  32. 32. Scaling with Coherence Nº32
  33. 33. Scaling Java Applications Conversational State User sessions Application State Persistent State Cache access patterns Data Grid as System of Record (SoR) Nº33
  34. 34. Scaling the Conversational State Normally, session data that cannot be lost is saved in a database As a result, application scalability is limited to database scalability Session data can be stored in a Data Grid instead Get the best of both worlds Performance of in-memory access Data consistency of a database Nº34
  35. 35. Scaling the Conversational State Coherence*Web is an out-of-the-box solution for reliably scaling HTTP sessions No coding required; simply run the instrumentation program on pre-existing WAR files Support for popular web containers WebLogic WebSphere OC4J Tomcat Jetty Nº35
  36. 36. Scaling the Persistent State Scaling the data tier along with the application tier is a challenge with Java applications Data Grids can help applications scale the data tier Simple Caching read-only data Intermediate Caching read-write data Advanced Transactional caching Data Grid is System of Record (SoR) Nº36
  37. 37. Cache Access Patterns ORM L2 Cache Aside Read Through Write Through Write Behind Nº37
  38. 38. ORM L2 Cache Configure ORM to cache database data Domain Objects Data Access ORM Data Store Cache Nº38
  39. 39. ORM L2 Cache Advantages Requires little to no coding Disadvantages Caching database data incurs cost of object building Data Grid capabilities cannot be used, Data Grid becomes a regular cache Nº39
  40. 40. Cache Aside Cache Aside pattern means the developer manages the contents of the cache manually Domain Objects Data Access Cache ORM Data Store Nº40
  41. 41. Cache Aside Requires the following: Check the cache before reading from data source Put data into cache after reading from data source Evict or update cache when updating data source Cache Aside can be written as a core part of the application logic, or it can be a cross cutting concern if the data access method is generic Nº41
  42. 42. Cache Aside Advantages Developer has full control over data access operations Disadvantages Data Grid features may be harder to use with this architecture; it may be used only as a cache Nº42
  43. 43. Read Through Cache is in between Data Access and Data Source Data access must happen through the cache If there is a cache miss, the cache will load the data from the database automatically Nº43
  44. 44. Read/Write Through Data Access Cache Server Cache Client ORM Data Store Nº44
  45. 45. Read Through Advantages Concurrent access operations are handled automatically (only one SELECT issued to the database), thus reducing database load Seamless integration with cache Disadvantages Data is only loaded when object is requested by key (instead of by query) Nº45
  46. 46. Write Through Like Read Through, cache sits between Data Access and Data Source Updates to the cache are written synchronously to the database Advantages Seamless integration with cache Write to cache can be rolled back upon database error Disadvantages Write performance can only scale as far as the database will allow Nº46
  47. 47. Write Behind Similar to Write Through Writes are queued up and executed asynchronously Data Grid is System of Record (SoR) Nº47
  48. 48. Write Behind Data Access Cache Server Queue Cache Client ORM Data Store Nº48
  49. 49. Write Behind Advantages Scalability is no longer limited to the database Provides much greater scalability and performance for write heavy applications Application can continue to function upon database failure Disadvantages Data in queue is not disk durable (but data is durable in case of a server failure) In the (unlikely) event of an entire cluster failure, there will be data loss Nº49
  50. 50. TopLink CacheLoader & CacheStore Coherence 3.3 includes TopLink Essentials JPA CacheLoader and CacheStore Coherence will support Oracle TopLink and EclipseLink CacheLoader and CacheStore in upcoming release. Nº50
  51. 51. Typical Web Application HTTP Sessions Service Interfaces Data Store Domain Objects Data Access Nº51
  52. 52. Web Application using Data Grid HTTP Sessions Service Interfaces Data Grid Data Store Domain Objects Data Access Nº52
  53. 53. Conclusion The most difficult scaling challenges are providing data access for stateful applications across a cluster/grid Using a Data Grid such as Coherence, Java applications can enjoy reliable, fast, and linearly scaleable data access Coherence can send the processing to the data—instead of the data to the processing—to support parallel processing that greatly improves system throughput Coherence provides a simple reliable approach to scaling Java applications Nº53
  54. 54. Q&A Nº54