Smith Scaling Java Applications With Coherence
-
Upload
snoop-consulting -
Category
Technology
-
view
3.919 -
download
4
description
Transcript of Smith Scaling Java Applications With Coherence
Scaling Java
Applications with Oracle Coherence
Leveraging the Power of Data Grids
Shaun Smith
Nº2
Speaker
Product Manager for Oracle TopLinkWorking with object-relational and object-XML mapping technology for over 10 years.Involved with Coherence/TopLink Integration
Eclipse Persistence Services Project (EclipseLink) Ecosystem Development LeadEclipse Dali JPA Tools Project Co-LeadEclipse Teneo Project Committer
Nº3
Agenda
Scaling Challenges for Java Applications
Coherence Data Grid
Scaling with Coherence
Nº4
Scaling Challenges
Nº5
Types of Application State
Request StateRequest/ResponseHTTP/RMI
Conversational (Transient) StateSpans multiple requestsScoped to a single “user”HTTP Sessions/Stateless Session Beans
Persistent (Durable) StatePermanent durable storageRelational Databases
Nº6
Request State Characteristics
Short lived Life span measured in milliseconds to seconds
Immutable and scoped to a single userAlmost 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º7
Conversational State Characteristics
Longer lived Life span measured in seconds to minutes
Mutable and scoped to a single userNot quite single writer, may have to deal with simultaneous requests from a user
PortletsFramesMultiple clicks
Load balancing issues: failover/failback/rebalancingOften recoverable
Worst case, by restarting the session
Nº8
Persistent State Characteristics
Long livedLife span often measured in yearsOften have regulatory requirements
Mutable and globally sharedPossible interaction and contention from all usersConcurrency and data consistency are hard to combine
Nº9
Scaling Characteristics
Request State
Easiest to scaleAdd more hardware to handle extra HTTP/RMI connections
Conversational State
Sticky Sessions without session replicationScales well, but data loss if node fails
Session replicationWorks well for small - medium applicationsCluster may be incoherent upon high load
Persistent State
Most difficult to scaleAbsolute requirement for data consistency makes scaling difficult (but possible)
Nº10
Typical Web Application
HTTP Sessions
Service Interfaces
Domain Objects
Data Access
Data Store
Nº11
Typical Web Application
HTTP Sessions
Service Interfaces
Domain Objects
Data Access
Data Store
Applications that cannot loose session data may have scaling challenges
with session state
Nº12
Typical Web Application
HTTP Sessions
Service Interfaces
Domain Objects
Data Access
Data Store
Applications that cannot loose session data may have scaling challenges
with session state
Scaling the application tier may cause the database to be a scalability
bottleneck
Nº13
Data Grid
Nº14
Introducing the Data Grid
Data Management & Clustering SolutionLive, transactional data in-memoryAutomatic partitioning of application dataSingle holistic view of application dataAbility to search, analyze, process information
Nº15
Oracle Coherence Data Grid
Communication via unicast UDPSpecialized protocol maintains cluster membership and data partitioningNo single point of failureTrue peer to peer system
Nº16
Partitioned Topology: Data Access
Data spread and backed up across nodesTransparent to developerMembers have access to all dataAll data locations are known - no lookups & no registry
Nº17
Partitioned Topology: Data Update
Synchronous UpdateAvoids potential data loss & corruptionPredictable performanceBackup partitions are partitioned away from primaries for resilienceNo engineering requirement to setup primaries or backups
Nº18
Partitioned Topology: Recovery
Membership changes (members added or removed)Other members, in parallel, recover/repartitionNo in-flight operations lostSome latency due to higher priority of recovery
Nº19
Using Coherence
Nº20
Cache Interfaces
Map, CacheMap, ConcurrentMap
Traditional Map interface, 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º21
Traditional Map Interface
Implements Map interfaceDrop in replacement. Full concurrency control. Multi-threaded. Scalable and resilient!get, put, putAll, size, clear, lock, unlock…
Implements JCache interfaceExtensive support for a multitude of expiration policies, including none!
More than “just a Cache”. More than “just a Map”
Nº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”));
System.in.read();} Joins / Establishes a clusterPlaces 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º23
Clustered Hello World…
public static void main(String[] args) throwsIOException {
NamedCache nc = CacheFactory.getCache(“test”);System.out.println(nc.get(“message”));
}
Joins / Establishes a clusterRetrieves the Entry from the Cache.Displays itStart as many applications as you like… they all cluster the are able to share the values in the cache
Nº24
Demo
Nº25
Observable Interface
Real-time filterable (bean) events for entry insert, update, deleteFilters applied in parallel (in the Grid)Filters completely extensibleA 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º26
Observable Interface
Nº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º28
Features : QueryMap
Interface
Nº29
Demo
Nº30
Features : InvocableMap
Interface
Execute processors against an Entry, a Collection or a FilterExecutions 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º31
Features : InvocableMap
Interface
Nº32
Scaling with Coherence
Nº33
Scaling Java Applications
Conversational StateUser sessionsApplication State
Persistent StateCache access patternsData Grid as System of Record (SoR)
Nº34
Scaling the Conversational State
Normally, session data that cannot be lost is saved in a databaseAs a result, application scalability is limited to database scalabilitySession data can be stored in a Data Grid insteadGet the best of both worlds
Performance of in-memory accessData consistency of a database
Nº35
Scaling the Conversational State
Coherence*Web is an out-of-the-box solution for reliably scaling HTTP sessionsNo coding required; simply run the instrumentation program on pre-existing WAR filesSupport for popular web containers
WebLogicWebSphereOC4JTomcatJetty
Nº36
Scaling the Persistent State
Scaling the data tier along with the application tier is a challenge with Java applicationsData Grids can help applications scale the data tier
SimpleCaching read-only data
IntermediateCaching read-write data
AdvancedTransactional cachingData Grid is System of Record (SoR)
Nº37
Cache Access Patterns
ORM L2Cache AsideRead ThroughWrite ThroughWrite Behind
Nº38
ORM L2 Cache
Configure ORM to cache database data
Data Access
ORM
Cache
Data Store
Domain Objects
Nº39
ORM L2 Cache
AdvantagesRequires little to no coding
DisadvantagesCaching database data incurs cost of object buildingData Grid capabilities cannot be used, Data Grid becomes a regular cache
Nº40
Cache Aside
Cache Aside pattern means the developer manages the contents of the cache manually
Data Access
ORM
Cache
Data Store
Domain Objects
Nº41
Cache Aside
Requires the following:Check the cache before reading from data sourcePut data into cache after reading from data sourceEvict 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º42
Cache Aside
AdvantagesDeveloper has full control over data access operations
DisadvantagesData Grid features may be harder to use with this architecture; it may be used only as a cache
Nº43
Read Through
Cache is in between Data Access and Data SourceData access must happen through the cacheIf there is a cache miss, the cache will load the data from the database automatically
Nº44
Read/Write Through
Data Access
ORMCache Client
Data Store
Cache Server
Nº45
Read Through
AdvantagesConcurrent access operations are handled automatically (only one SELECT issued to the database), thus reducing database loadSeamless integration with cache
DisadvantagesData is only loaded when object is requested by key (instead of by query)
Nº46
Write Through
Like Read Through, cache sits between Data Access and Data SourceUpdates to the cache are written synchronously to the databaseAdvantages
Seamless integration with cacheWrite to cache can be rolled back upon database error
DisadvantagesWrite performance can only scale as far as the database will allow
Nº47
Write Behind
Similar to Write ThroughWrites are queued up and executed asynchronouslyData Grid is System of Record (SoR)
Nº48
Write Behind
Data Access
ORMCache Client
Data Store
Cache Server
Queue
Nº49
Write Behind
AdvantagesScalability is no longer limited to the databaseProvides much greater scalability and performance for write heavy applicationsApplication can continue to function upon database failure
DisadvantagesData 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º50
TopLink CacheLoader
& CacheStore
Coherence 3.3 includes TopLink Essentials JPA CacheLoader and CacheStoreCoherence will support Oracle TopLink and EclipseLink CacheLoader and CacheStore in upcoming release.
Nº51
Typical Web Application
HTTP Sessions
Service Interfaces
Domain Objects
Data Access
Data Store
Nº52
Web Application using Data Grid
HTTP Sessions
Service Interfaces
Domain Objects
Data Access
Data StoreDataGrid
Nº53
The most difficult scaling challenges are providing data access for stateful applications across a cluster/gridUsing a Data Grid such as Coherence, Java applications can enjoy reliable, fast, and linearly scaleable data accessCoherence 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
Conclusion
Nº54
Q&A