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

1. Shaun Smith
Scaling Java
Applications with
Oracle Coherence
Leveraging the Power of Data Grids

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. Agenda
Scaling Challenges for Java Applications
Coherence Data Grid
Scaling with Coherence
Nº3

4. Scaling Challenges
Nº4

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. 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. 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. 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. 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. Typical Web Application
HTTP Sessions
Service Interfaces
Data Store
Domain Objects
Data Access
Nº10

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. 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. Data Grid
Nº13

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. 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. 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. 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. 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. Using Coherence
Nº19

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. 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. 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 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. 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. Demo
Nº24

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. Observable Interface
Nº26

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. Features : QueryMap Interface
Nº28

29. Demo
Nº29

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. Features : InvocableMap Interface
Nº31

32. Scaling with Coherence
Nº32

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. 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. 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. 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. Cache Access Patterns
ORM L2
Cache Aside
Read Through
Write Through
Write Behind
Nº37

38. ORM L2 Cache
Configure ORM to cache database data
Domain Objects
Data Access
ORM Data Store
Cache
Nº38

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. 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. 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. 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. 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. Read/Write Through
Data Access Cache Server
Cache Client ORM
Data Store
Nº44

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. 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. Write Behind
Similar to Write Through
Writes are queued up and executed asynchronously
Data Grid is System of Record (SoR)
Nº47

48. Write Behind
Data Access Cache Server
Queue
Cache Client ORM
Data Store
Nº48

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. 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. Typical Web Application
HTTP Sessions
Service Interfaces
Data Store
Domain Objects
Data Access
Nº51

52. Web Application using Data Grid
HTTP Sessions
Service Interfaces
Data
Grid Data Store
Domain Objects
Data Access
Nº52

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. Q&A
Nº54