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