<Insert Picture Here> TopLink Grid: Scaling JPA applications with Coherence Shaun Smith—Principal Product Manager [email protected] Java Persistence: The Problem Space Customer <customer id=“…”> <name>…</name> id: int JAXB/SDO … name: String </contact-info> creditRating: int </customer> Java XML XR (XML- Relational) JPA CUST ID NAME C_RATING JPA: Java Persistence API Relational JAXB: Java Architecture for XML Binding SDO: Service Data Objects EclipseLink Project • JPA 2.0 Reference Implementation (JSR 317) • Provides JPA, JAXB, SDO, DBWS, and EIS persistence services • Open source Eclipse project • Founded by Oracle with the contribution of full Oracle TopLink source code and tests • Based upon product with 12+ years of commercial usage EclipseLink: Distributions • Eclipse.org • www.eclipse.org/eclipselink/downloads • Eclipse P2 & Maven repositories • Oracle • TopLink 11g • WebLogic Server 10.3 • GlassFish v3 • Replaces TopLink Essentials • JPA 2.0 Reference Implementation • Spring Source: Framework & Bundle Repo • JOnAS Application Server 5.1 • JEUS TmaxSoft EclipseLink JPA • Supports Java EE, Java SE, Web, Spring, and OSGi • Supports all leading RDMS with platform specific features • Best JPA for the Oracle Database—supporting advanced features • Extensible and pluggable • Key infrastructure: • Caching, Locking, Query Framework, Mapping, … • … plus many valuable advanced features JPA Performance • Mapping • Querying – Optimized Graph Loading: Join and Batch – Projections, Streaming, Range – Stored Procedures/Functions • Transactions – Minimal, Ordered, and Deferred Changes – Sequence pre-allocation • Caching – Cache reusable data and leverage in future operations Advanced Performance Features Minimal Writes, Updates Automatic change detection Batch Reading, Writing Caching policies and sizes SQL ordering Parameterized SQL (binding) Transformation support Pre-allocation of sequence Existence checks numbers Stored procedures Cache Coordination Statement Caching Optimistic, Pessimistic locking Scrolling cursors Joining object retrieval optimization Projection Queries In memory querying Fetch Groups Dynamic queries “Just in Time” reading AND MUCH MORE Example JPA Client Code … Mechanics of a JPA Application Step 1 Step 2 Step 3 Application Logic Application Logic Application Logic Create/ Modify Entities JPA JPA JPA Read Insert/ Entities Update Entities JPA with Cache TX n TX n+1 Application Logic Application Logic Cache hits JPA avoid object build cost ReadTX Commit Entities Scaling Java Persistence Java Scaling Application Application JPA Application Application Application Application Application JPA Application Application Application . Application Application JPA Application Application Application EclipseLink in a Cluster Application Logic Application Logic EntityManager EntityManager Persistence Persistence Context Context EntityManagerFactory EntityManagerFactory Need to keep Shared Shared Caches Shared Cache Coherent Cache Traditional Approaches to Scaling JPA • Historically there have been two strategies for scaling EclipseLink JPA applications into a cluster: • Disable Shared Caching • No shared cache • Always Refresh • Cache Coordination • Communicate changes via messaging Strategy 1: Disable Shared Cache Application Logic Application Logic EntityManager EntityManager Persistence Persistence Context Context EntityManagerFactory EntityManagerFactory Disable Shared Cache • Ensures all nodes have coherent view of data. • Database is always right • Each transaction queries all required data from database and constructs Entities • No inter-node messaging • Memory footprint of application increases as each transaction has a copy of each required Entity • Every transaction pays object construction cost for queried Entities. • Database becomes bottleneck Strategy 2: Cache Coordination Application Logic Application Logic EntityManager EntityManager Persistence Persistence Context Context EntityManagerFactory EntityManagerFactory Shared Cache Shared Cache Coordination Cache Cache Coordination • Minimize stale entity caching across loosely coupled nodes. • Database is always right • Optimistic locking prevents corruption • Fresh Entities retrieved from shared cache • Stale Entities refreshed from database on access • Creation and/or modification of Entity results in message to all other nodes • Shared cache size limited by heap of each node • Cost of coordinating depends on messaging technology and application • cost of communication and processing may eventually exceed value of caching Extending EclipseLink’s Cache • EclipseLink provides out of box support for – Object caching: Shared, Isolated, Transactional – Cache Coordination • EclipseLink’s Caching and Querying extension points – Cache Interceptors – Query Redirectors • EclipseLink can be extended to support 3rd party grid caching solutions Introducing TopLink Grid • TopLink Grid allows Java developers to transparently leverage the power of the Coherence data grid • TopLink Grid combines: • the simplicity of application development using the Java standard Java Persistence API (JPA) with • the scalability and distributed processing power of Oracle’s Coherence Data Grid. • Supports 'JPA on the Grid' Architecture • EclipseLink JPA applications using Coherence as a shared (L2) cache replacement along with configuration for more advanced usage Oracle TopLink 11gR1 • Oracle’s Enterprise Java Persistence Framework • Includes open source EclipseLink with Commercial Support • Certified on WebLogic and redistributed by Oracle as part of TopLink product and in WebLogic Server and Oracle GlassFish • TopLink Grid: JPA integration with Coherence • Tooling Support in JDeveloper and Eclipse TopLink Grid with Coherence Cache Application Logic Application Logic EntityManager EntityManager Persistence Persistence Context Context EntityManagerFactory EntityManagerFactory Coherence Oracle Coherence Data Grid Distributed in Memory Data Management • Provides a reliable data Enterprise Real Time Web tier with a single, Applications Clients Services consistent view of data Data Services • Enables dynamic data capacity including fault Oracle Coherence tolerance and load Data Grid balancing • Ensures that data capacity scales with processing capacity Databases Mainframes Web Services Coherence Topology Example Distributed Topology • Data spread and backed up across Members • Transparent to developer • Members have access to all Data • All Data locations are known – no lookup & no registry! 23 Coherence Update Example Distributed Topology • 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 • Automatically and Dynamically Managed 24 Coherence Recovery Example Distributed Topology • No in-flight operations lost • Some latencies (due to higher priority of recovery) • Reliability, Availability, Scalability, Performance are the priority • Degrade performance of some requests 25 JPA with Coherence Cluster Node 1 Cluster Node N Application Logic Application Logic . JPA JPA Coherence ReadTX Commit Entities TopLink Grid—Configurations • Grid Cache—Coherence as Shared (L2) Cache • Configurable per Entity type • Entities read by one grid member are put into Coherence and are immediately available across the entire grid • Grid Read • All supported read queries executed in the Coherence data grid • All writes performed directly on the database by TopLink (synchronously) and Coherence updated • Grid Entity • All supported read queries and all writes are executed in the Coherence data grid Grid Cache ('Cache Aside') • Reading: • Primary Key queries check JPA Application Coherence first. • If found in Coherence, Entity is returned. PK • If not found the database is Query queried. • Entities queried from database Insert/ are put() into Coherence and Update/ Query returned to the application. Delete • Writing: • All inserts, updates, and deletes are directed to the database • On successful commit, Coherence is updated Grid Cache—Leveraging Cache • Cache is used when processing database results • EclipseLink extracts primary keys from results and checks cache to avoid object construction. • Even if a SQL query is executed, an object cache can still improve application throughput by eliminating object construction costs for cached Entities Grid Read • All writes performed directly JPA Application on database. • Primary key queries result in get() on Coherence • JPQL queries, e.g., Select e from Employee E Query are translated to Filters and executed in Coherence • CacheLoaders should be configured to query database with PK query on cache miss Insert/ Update/ PK Delete Query Grid Entity—Reading • Primary key queries result in JPA Application get() on Coherence • JPQL queries, e.g., Select e from Employee E are translated to Filters and executed in Coherence Query • The database is not queried by EclipseLink. CacheLoaders may be PK configured to query Query database with PK query on cache miss Grid Entity—Writing • Applications commit JPA JPA Application transactions with new, deleted, or modified Entities • EclipseLink put()s all new and updated Entities into Put/ Coherence and remove()s Remove deleted Entities. CacheStores may be configured to write cache changes to the database using TopLink Grid Insert/ Update/ Delete Grid Enabling JPA Entities • A single annotation is added to an Entity to enable Coherence usage, e.g.,