Oracle Coherence 3.5

Table of Contents

Oracle Coherence 3.5

Credits

Foreword

A word about the author

About the author

Acknowledgements

About the co-authors

About the reviewers

Preface

Introducing Oracle Coherence

Distributed caching

Distributed queries

In-place and parallel processing

Cache events

Coherence within the Oracle ecosystem

Coherence usage scenarios

Oracle Coherence editions

What this book covers

What you need for this book

Who this book is for

Who this book is not for

Conventions

Reader feedback

Customer support

Errata

Piracy

Questions

1. Achieving Performance, Scalability, and Availability Objectives

Achieving performance objectives

Dealing with latency

Minimizing bandwidth usage

Coherence and performance

Achieving scalability

Stateless services do not exist

Scaling a database is hard

Database scale-out approaches

Master-slave replication

Database clustering

Database sharding

Return of the state

Using Coherence to reduce database load

Coherence and master-slave databases

Coherence and database clusters

Coherence and database sharding

Coherence and scalability

Achieving high availability

Adding redundancy to the system

Redundancy is not enough

Coherence and availability

Putting it all together

Design for performance and scalability

Set performance goals at each level

Measure and monitor

Educate your team

Summary

2. Getting Started

Installing Coherence

What's in the box?

Starting up the Coherence cluster

Troubleshooting cluster start-up

Multicast issues

Binding issues

Accessing the data grid

Coherence console

Creating caches

Working with the cache

Configuring the development environment

Referencing necessary JAR files

Enabling IntelliSense for configuration files

Starting Coherence nodes within the IDE

Creating a private cluster

Configuring Coherence

Operational configuration

Configuring logging

Configuring a private cluster

Using the Coherence API

The basics: NamedCache and CacheFactory

The Hello World example

Coherence API in action: Implementing the cache loader

Loader design

Implementing CsvSource

Implementing CoherenceTarget

Testing the Cache loader

Testing and debugging Coherence applications

Summary

3. Planning Your Caches

Anatomy of a clustered cache

Clustered cache topologies

Replicated Cache service

Read performance

Write performance

Data set size

Coherence node size on modern JVMs

Fault tolerance

When to use it?

Partitioned Cache service

Read performance

Write performance

Data set size

Fault tolerance

When to use it?

Near cache

Near cache invalidation strategies

None

Present

All

Auto

When to use it?

Continuous Query Cache

Backing maps

Local cache

External backing map

Paged external backing map

Overflow backing map

Read-write backing map

Partitioned backing map

Cache configuration

Caching schemes

Distributed cache scheme

Local cache scheme

Near cache scheme

Read-write backing map scheme

Partitioned backing map

Partitioned read-write backing map

Cache mappings

Sample cache configuration

Summary

4. Implementing Domain Objects

Introducing the Coherent Bank sample application

Coherent Bank requirements

Coherent Bank domain model

Domain model building blocks

Entities and aggregates

Implementing entities

Identity management

Creating entity instances

Managing entity relationships

Dealing with dependencies

Specifying data affinity

Value objects

Implementing the Money value object

Value objects as identifiers

Services

Implementing the CurrencyConverter service

Factories

Repositories

Implementing object serialization

POF basics

POF context

ConfigurablePofContext

Implementing serialization code

PortableObject or PofSerializer?

Collection serialization with POF

Adding support for schema evolution

Implementing Evolvable objects

Implementing serialization for Evolvable objects

Summary

5. Querying the Data Grid

Built-in filters

Value extractors

Reflection extractor

Other built-in value extractors

IdentityExtractor

ChainedExtractor and MultiExtractor

PofExtractor

Implementing a custom value extractor

Simplifying Coherence queries

Filter builder

Obtaining query results

Controlling query scope using data affinity

Querying near cache

Sorting the results

Paging over query results

Using indexes to improve query performance

Anatomy of an Index

Creating indexes

Coherence query limitations

Aggregators

Built-in aggregators

Using aggregators

Implementing LookupValuesAggregator

Summary

6. Parallel and In-Place Processing

Entry processors

In-place processing

Implementing WithdrawalProcessor

Cache service re-entrancy

Accessing the backing map directly

Built-in entry processors

VersionedPut and VersionedPutAll

PriorityProcessor

ExtractorProcessor

UpdaterProcessor

Invocation service

Configuring the invocation service

Implementing agents

Executing agents

CommonJ Work Manager

Work Manager API basics

Defining work

Scheduling work

Processing the results

Coherence Work Manager limitations

Coherence Incubator

Summary

7. Processing Data Grid Events

Cache events

Registering map listeners

Programmatic listener registration

Listening to specific events

Listening for specific property changes

Transforming map events

Registering listeners within the cache configuration file

Making any map observable

Backing map events

Implementing a low-balance listener

AbstractBackingMapListener

Low-balance listener

Registering a backing map listener

Map triggers

Using map triggers for data validation

Data validation framework

Implementing validation trigger

Registering map triggers

Continuous query cache

Observing a continuous query cache

Using a continuous query cache as a substitute for a replicated cache

Summary

8. Implementing the Persistence Layer

Cache aside

Read-through caching

Implementing read through

Introducing the read-write backing map

Using Spring Framework with a read-write backing map

Refresh ahead

Using refresh ahead to pre-fetch exchange rates

Additional considerations

Write through

Write behind

Using write behind for accounts and transactions

Write behind and storeAll

Handling write-through/write-behind failures

Cluster member failures

Store failures

Write behind and eviction

Write behind and deletes

Configuring backup with a read-write backing map

Backup with read through

Backup with write behind

Built-in CacheStore implementations

Using the Coherence JPA CacheStore

Summary

9. Bridging Platform and Network Boundaries

Coherence networking

Coherence*Extend overview

Configuring Coherence*Extend

Configuring proxy servers

Configuring clients

Configuring remote cache scheme

Mapping cache names to caches

Configuring a remote invocation service

Address providers

Handling connection or proxy server failure

Coherence*Extend limitations

Explicit concurrency control

Executing invocable agents via Coherence*Extend

Securing proxy servers

Using network filters

Built-in network filters

Compression filter

Symmetric encryption filter

Implementing a custom network filter

Summary

10. Accessing Coherence from .NET

.NET client configuration

Coherence configuration files in .NET

Operational descriptor

Cache configuration

POF configuration

Resource loading in Coherence for .NET

Resource abstraction

Protocols and resource loader

Approaches to .NET client configuration

Convention-based configuration

Explicit configuration

Programmatic configuration

Implementing the client application

Basic Cache Operations

Implementing data objects

Implementing the IPortableObject interface

Implementing the external serializer

Executing queries

Implementing filters and value extractors

Implementing PropertyExtractor in C#

Executing the aggregators and entry processors

Listening for cache events

Cache listeners

Event marshalling in Windows Forms applications

Continuous Query Cache

Data binding with Windows Presentation Foundation (WPF)

Summary

11. Accessing Coherence from C++

Configuring Coherence C++

Managed object model

Handles, Views, and Holders

Managed object creation

Casting and type checking

Handling exceptions

Class hierarchy namespaces

Implementing a Coherence C++ client application

Implementing Cacheable C++ Data Objects

Managed adapter

Data object serialization

Implementing managed classes

Understanding specifications

Factory methods

Member variables

Implementing constructors

Implementing methods

Implementing the PortableObject interface

Implementing external serializer

Executing queries

Value extractors

Extracting values from locally cached objects

PofExtractor

Implementing PropertyExtractor in C++

Filters

Performing a query in C++

Executing aggregators and entry processors

Implementing DepositProcessor in C++

Listening for cache events

Cache listeners

Standard type integration

Summary

12. The Right Tool for the Job

A. Coherent Bank Sample Application

Prerequisites

Sun Java JDK 1.6

Microsoft Visual Studio 2008

Oracle Coherence 3.5.3

Ant 1.7+

NAnt 0.86

Installation

Deploying the Java Application

Deploying the C++ Application

Deploying the .NET Application

Shutting everything down

Review the code

Index

Oracle Coherence 3.5

Aleksandar Seović

Mark Falco

Patrick Peralta

Oracle Coherence 3.5

Copyright © 2010 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

First published: April 2010

Production Reference: 1240310

Published by Packt Publishing Ltd.

32 Lincoln Road

Olton

Birmingham, B27 6PA, UK.

ISBN 978-1-847196-12-5

www.packtpub.com

Cover Image by Vinayak Chittar (<[email protected]>)

Credits

Authors

Aleksandar Seović

Mark Falco

Patrick Peralta

Reviewers

Rob Harrop

Jimmy Nilsson

Patrick Peralta

Steve Samuelson

Robert Varga

Acquisition Editor

James Lumsden

Development Editor

Dilip Venkatesh

Technical Editor

Arani Roy

Indexer

Rekha Nair

Editorial Team Leader

Mithun Sehgal

Project Team Leader

Lata Basantani

Project Coordinator

Srimoyee Ghoshal

Proofreader

Chris Smith

Graphics

Geetanjali Sawant

Production Coordinator

Shantanu Zagade

Cover Work

Shantanu Zagade

Foreword

There are a few timeless truths of software development that are near-universally accepted, and have become the basis for many a witty saying over the years. For starters, there's Zymurgy's First Law of Evolving Systems Dynamics, which states:

Once you open a can of worms, the only way to re-can them is to use a bigger can.

And Weinberg's Second Law, which postulates that,

If builders built buildings the way that programmers wrote programs, the first woodpecker to come along would destroy civilization.

There is true brilliance in this timeless wit, enjoyed and appreciated by generation after generation of software developers.

The largest set of challenges that the modern programmer faces, and thus the source of most of the wit that we as programmers revel in, revolves around the seemingly boundless growth of complexity. Hardware becomes more complex. Operating systems become more complex. Programming languages and APIs become more complex. And the applications that we build and evolve, become more and more complex.

The complexity of a system always seems to hover ever so slightly on the far side of manageable, just slightly over the edge of the cliff. And while our work reality is a world full of complexity—or perhaps because of that complexity—we gravitate toward the pristine and the simple. While our day-to-day lives may be focused on diagnosing failures in production systems, our guiding light is the concept of continuous availability. While we may have to manually correct data when things go wrong, our aspirations remain with data integrity and information reliability. While the complexity of the legacy applications that we manage forces us to adopt the most expensive means of adding capacity, our higher thoughts are focused on commodity scale-out and linear scalability. And while the complex, layered, and often twisted system designs result in hopelessly slow responses to user actions, we fundamentally believe that users should experience near-instant responses for almost any conceivable action they take.

In a word, we believe in the ilities.

Availability. Reliability. Scalability. Performance. These are attributes that we wish to endow each and every one of our systems with. If a system lacks continuous availability, its users will be directly impacted by failures within the system. If a system lacks information reliability, then users will never know if the information they are using can be trusted. If a system lacks scalability, its growing popularity will overwhelm and kill it—it will fail just as it begins to succeed! If a system lacks performance, it will inflict a dose of pain upon its users with each and every interaction.

We wish to achieve these ilities because we wish for our labors to be beneficial to others, and we hope that the value that we provide through these systems endures far longer than the passing whims and fads of technology and industry.

Perhaps no greater revolution has occurred in our industry than the World Wide Web. Suddenly, the systems we provide had a limitless audience, with instant access to the latest and greatest versions of our software. Users are so accustomed to instant responses from one application that failure to achieve the same will cause them to quickly abandon another. Downtime no longer represents an inconvenience—for major websites, their online foibles have become headline news on the printed pages of the Wall Street Journal!

At the same time, the competitive landscape has forced companies, and thus their IT departments, to act and react far more quickly than before. The instant popularity of a particular good, service, or website can bring mind-boggling hordes of unexpected—though generally not undesired—users. Companies must be able to roll out new features and capabilities quickly, to grow their capacity dynamically in order to match the increase in users, and to provide instantaneous responsiveness with correct and up-to-date information to each and every user.

These are the systems that Oracle Coherence was designed to enable. These are the systems that this book will help you build.

If there was only one piece of advice that I could instill into the mind of a software architect or developer responsible for one of these systems, it would be this: architecture matters, and in systems of scale and systems that require availability, architecture matters absolutely! Failure to achieve a solid architecture will doom in advance any hope of significant scalability, and will leave the effects of failure within the system to pure chance.

No amount of brilliant programming can make up for a lack of architectural foresight. Systems do not remain available by accident, nor do they scale by accident. Achieving information reliability in a system that remains continuously available and provides high performance under varying degrees of load and scale is an outcome that results only when a systematic and well-conceived architecture has been laid down. Availability, reliability, scalability, and performance must be the core tenets of an architecture, and they must be baked into and throughout that architecture.

If there were a second piece of advice that I could confer, it would be this: as a craftsman or craftswoman, know your tools, and know them well. Using Oracle Coherence as part of a system does not ensure any of the ilities by itself; it is simply a powerful tool for simultaneously achieving those ilities as part of a great architecture. This book is an effort to condense a huge amount of experience and knowledge into a medium of transfer that you can rehydrate into instant knowledge for yourself.

And the last piece of advice is this: don't believe it until you see it; make sure that you push it until it fails. While testing, if you don't overload the system until it breaks, then you can't be certain that it will work. If you don't pull the plug while it's running, then you can't be certain that it will handle failure when it truly matters. Don't be satisfied until you understand the limits of your systems, and until you appreciate and understand what lies beyond those boundaries.

A word about the author

I first met Aleks Seović in 2005. I was attending the Javapolis (now Devoxx) conference in Antwerp with the express purpose of persuading Aleks to create the .NET implementation of Coherence. I had known of him through his work in creating the Spring.NET framework, and knew that there was only one person whom I wanted to lead the creation of our own product for .NET. As they say, the rest is history: We hit it off smashingly, and found a great deal of common ground in our experiences with enterprise systems, the challenges of distributed computing, architecting for scalable performance and high availability, and the need for seamless and reliable information exchange between Java and .NET applications.

Aleks has such a great ability to understand complex systems, and such a compelling manner of reducing complexity into simple concepts, that I was ecstatic when he told me that he was writing this book. Starting a book is no challenge at all, but finishing a book is a great feat. Many years of work have gone into these pages. May you enjoy and profit from this book as deeply as I have enjoyed and profited from my conversations with Aleks over these past years.

Cameron Purdy

Lexington, MA

January 2010

About the author

Aleksandar Seović is the founder of and managing director at S4HC, Inc., where he leads professional services practice. He works with customers throughout the world to help them solve performance and scalability puzzles and implement innovative solutions to complex business and technical problems.

Aleksandar lead the implementation of Oracle Coherence for .NET, a client library that allows applications written in any .NET language to access data and services provided by an Oracle Coherence data grid. He was also one of the key people involved in the design and implementation of Portable Object Format (POF), a platform-independent object serialization format that allows seamless interoperability of Coherence-based Java, .NET, and C++ applications.

Aleksandar is Oracle ACE Director for Fusion Middleware, and frequently speaks about and evangelizes Coherence at conferences, Java and .NET user group events, and Coherence SIGs. He blogs about Coherence and related topics at http://coherence.seovic.com.

Acknowledgements

First and foremost, I'd like to thank Cameron Purdy and Alex Gleyzer for giving me the opportunity to work on Coherence. It has been quite a journey—I still remember the day when we got a .NET application to connect to the cluster for the first time. Guys, it has been a privilege working with you all these years to make a great product even better.

I've heard many times that a book is never a single person's creation. Only now, after I have written one myself, I truly understand what that means.

I cannot thank enough my co-authors, Mark Falco and Patrick Peralta, members of the Coherence engineering team, who contributed two great chapters to the book. Patrick's chapter covers pretty much everything you need to know in order to integrate Coherence with persistent data sources. As for Mark's chapter on using the Coherence C++ client, well, let's just say that I would've had a really hard time writing that one myself.

The sample application for the book is the result of the hard work of my colleagues from Solutions for Human Capital: Ivan Cikić, Nenad Dobrilović, Marko Dumić, and Aleksandar Jević. They managed to deliver (once again) on a very tight schedule, and I am very proud of the final result. Thank you for all the help and for putting up with my last minute change requests—I know it wasn't easy at times, but you have done a wonderful job.

I can honestly say (and everyone who saw the first draft is my witness) that this book was significantly improved based on the feedback from many reviewers. The official reviewers for the book were Rob Harrop, Jimmy Nilsson, Patrick Peralta, Steve Samuelson, and Robert Varga, but Mark Falco, Cameron Purdy, Cristobal Soto, Phil Wheeler, and Andrew Wilson also provided invaluable feedback. Jimmy, it is mostly your fault that there is a sample application now demonstrating (among other things) how to build a clean, testable domain model that works well with Coherence.

Many members of Coherence engineering and Oracle's Architecture team were only an e-mail or phone call away when I had questions: Noah Arliss, Simon Bisson, Gene Gleyzer, Jason Howes, Rob Misek, Andy Nguyen, Brian Oliver, Jon Purdy, and Randy Stafford all helped at one point or another, whether they know it or not. Thank you for that, and thank you for building such a great product.

James Lumsden, Dilip Venkatesh, Rajashree Hamine, and Srimoyee Ghoshal from Packt Publishing provided necessary support when I needed it and helped me reach the finish line. James, I know the journey was much longer than either of us expected. Thank you for believing in me even when I didn't.

My partners at Solutions for Human Capital, Snejana Sevak, Aleksandar Jević, and Nebojša Peruničić, helped more than they realize by shielding me from the daily disturbances of running a business and allowing me to focus my energy on writing, and I thank them for that.

I would also like to thank all the clients and colleagues I worked with over the years. I learned something new from each one of you, and for that I am grateful.

Most importantly, I would like to thank my family. My wife Marija supported me from the moment I decided to work on this book, even though she knew that my already busy schedule would only get busier because of it. People who think astronauts' wives have it rough have never met the wife of a traveling geek who decides to write a book. Хвала, љубави.

To my children, Ana Maria and Novak, I am sorry I couldn't play with you as much as we all wanted, and promise to make it up to you. You are too young to understand why daddy was sleeping during the day and working at night, but that doesn't matter now. Daddy is back and loves you both very much!

About the co-authors

Mark Falco is a Consulting Member of Technical Staff at Oracle. He has been part of the Coherence development team since 2005 where he has specialized in the areas of clustered communication protocols as well as the Coherence for C++ object model. Mark holds a B.S. in computer science from Stevens Institute of Technology.

I would like to thank Aleks for the opportunity to contribute to this book and Tangosol for the years of fun and interesting work. Thank you Otti, Erika, and Mia for your encouragement and support.

Patrick Peralta is a Senior Software Engineer for Oracle (formerly Tangosol) specializing in Coherence and middleware Java. He wears many hats in Coherence engineering, including development, training, documentation, and support. He has extensive experience in supporting and consulting customers in fields such as retail, hospitality, and finance.

As an active member of the Java developer community he has spoken at user groups and conferences across the US including Spring One and Oracle Open World. Prior to joining Oracle, Patrick was a senior developer at Symantec, working on Java/J2EE based services, web applications, system integrations, and Swing desktop clients. Patrick has a B.S. in computer science from Stetson University in Florida.

He currently maintains a blog on Coherence and other software development topics at http://blackbeanbag.net.

I would like to express my appreciation and gratitude to those that provided valuable feedback, including Aleks Seović, Gene Gleyzer, Andy Nguyen, Pas Apicella, and Shaun Smith. Many thanks as well to my family, including my parents, siblings, and especially my wonderful wife Maria and son Isaac for providing me with joy and perspective on what is truly important in life.

About the reviewers

Rob Harrop is a respected speaker, author, entrepreneur, and technologist.

As Lead Engineer of SpringSource dm Server, Rob is driving SpringSource's enterprise middleware product line and ensuring that the company continues to deliver high-performance, highly scalable enterprise solutions.

With a thorough knowledge of both Java and .NET, Rob has successfully deployed projects across both platforms. He has extensive experience across a variety of sectors, in particular banking, retail, and government. Prior to joining SpringSource, he co-founded the UK-based software company Cake Solutions Limited and worked as a Lead Developer for a successful dotcom start-up.

Rob is the author of five books, including Pro Spring, a widely acclaimed, comprehensive resource on the Spring Framework.

Jimmy Nilsson has been working as a developer/architect for over 20 years.

He has authored Applying Domain-Driven Design and Patterns and .NET Enterprise Design.

Steve Samuelson has worked in IT for over 20 years across various industries including home building, finance, and education. Although experienced with Windows deployment and hardware, Steve prefers custom software development. Currently, Steve is the Chief Architect for an international education provider where he works with multiple technologies running under Unix and Windows. Steve's primary interest lies in Microsoft .NET development and tools, but he makes sure to keep up on emerging Java and Oracle technologies among others.

Robert Varga is a Lead Software Engineer at EPAM Systems. He has worked in various roles from Developer to Enterprise Architect on several large projects for various customers, mostly in the areas of insurance, online betting, online auctions, and finance. He is also an Oracle ACE since 2008.

Robert has worked on Java-based enterprise systems since 1998 and on various projects with the Coherence data grid since 2005. He is among the most active contributors to the Oracle Coherence support forums helping developers with questions about Oracle Coherence.

Preface

As an architect of a large, mission-critical website or enterprise application, you need to address at least three major non-functional requirements: performance, scalability, and availability.

Performance is defined as the amount of time that an operation takes to complete. In a web application, it is usually measured as time to last byte (TTLB)—the amount of time elapsed from the moment the web server received a request, until the moment the last byte of response has been sent back to the client. Performance is extremely important, because experience has shown us that no matter how great and full-featured an application is, if it is slow and unresponsive, the users will hate it.

Scalability is the ability of the system to maintain acceptable performance as the load increases, or to support additional load by adding hardware resources. While it is relatively simple to make an application perform well in a single-user environment, it is significantly more difficult to maintain that level of performance as the number of simultaneous users increases to thousands, or in the case of very large public websites, to tens or even hundreds of thousands. The bottom line is, if your application doesn't scale well, its performance will degrade as the load increases and the users will hate it.

Finally, availability is measured as the percentage of time an application is available to the users. While some applications can crash several times a day without causing major inconvenience to the user, most mission-critical applications simply cannot afford that luxury and need to be available 24 hours a day, every day. If your application is mission critical, you need to ensure that it is highly available or the users will hate it. To make things even worse, if you build an e-commerce website that crashes during the holiday season, your investors will hate you as well.

The moral of the story is that in order to keep your users happy and avoid all that hatred, you as an architect need to ensure that your application is fast, remains fast even under heavy load, and stays up and running even when the hardware or software components that it depends on fail. Unfortunately, while it is relatively easy to satisfy any one of these three requirements individually and not too difficult to comply with any two of them, it is considerably more difficult to fulfill all three at the same time.

Introducing Oracle Coherence

Over the last few years, In-Memory Data Grids have become an increasingly popular way to solve many of the problems related to performance and scalability, while improving availability of the system at the same time.

Oracle Coherence is an In-Memory Data Grid that allows you to eliminate single points of failure and single points of bottleneck in your application by distributing your application's objects and related processing across multiple physical servers.

There are several important points in the definition above:

Coherence manages application objects, which are ready for use within the application. This eliminates the need for repeated, and often expensive, loading and transformation of the raw data into objects.

Coherence distributes application objects across many physical servers while ensuring that a coherent, Single System Image (SSI) is presented to the application.

Coherence ensures that no data or in-flight operations are lost by assuming that any node could fail at any time and by ensuring that every piece of information is stored in multiple places.

Coherence stores data in memory in order to achieve very high performance and low latency for data access.

Coherence allows you to distribute not only application objects, but also the processing that should be performed on these objects. This can help you eliminate single points of bottleneck.

The following sections provide a high-level overview of Coherence features; the remainder of the book will teach you how, and more importantly, when to use them.

Distributed caching

One of the easiest ways to improve application performance is to bring data closer to the application, and keep it in a format that the application can consume more easily.

Most enterprise applications are written in one of the object-oriented languages, such as Java or C#, while most data is stored in relational databases, such as Oracle, MySql or SQL Server. This means that in order to use the data, the application needs to load it from the database and convert it into objects. Because of the impedance mismatch between tabular data in the database and objects in memory, this conversion process is not always simple and introduces some overhead, even when sophisticated O-R mapping tools, such as Hibernate or EclipseLink are used.

Caching objects in the application tier minimizes this performance overhead by avoiding unnecessary trips to the database and data conversion. This is why all production-quality O-R mapping tools cache objects internally and short-circuit object lookups by returning cached instances instead, whenever possible.

However, when you scale out your application across multiple servers, you will start running into cache synchronization issues. Each server will cache its own copy of the data, and will have no way of knowing if that same data has been changed on another server—in this case, the locally cached copy should be invalidated and evicted from the cache.

Oracle Coherence solves this problem by allowing you to distribute your cache across a cluster of machines, while providing a unified, fully coherent view of the data. This means that you can configure Coherence as an L2 cache for Hibernate or EclipseLink, and forget about distributed cache synchronization!

If this was all Coherence did, it would be impressive enough. However, it actually does so much more that I don't recommend using it purely as an L2 cache, unless you have an existing application that you need to scale out. While Coherence works like a charm as an L2 cache behind an O-R mapper, this architecture barely scratches the surface of what Coherence can do. It is like killing an ox for a pound of meat, as the Serbian proverb says.

It is much more powerful to use Coherence as a logical persistence layer of your application, which sits between the application logic and the physical data store. Whenever the application needs data, it asks Coherence for it. If the data is not already in the cache, Coherence will transparently load it from the data store, cache it, and return it to the application. Similarly, when the application needs to store data, it simply puts objects into the cache, and Coherence updates the underlying data store automatically.

This architecture is depicted in the following diagram and is the basis for the architecture we will use throughout the book:

Although Coherence is not really a persistent store in the preceding scenario, the fact that the application thinks that it is decouples the application from the data store and enables you to achieve very high scalability and availability. You can even configure Coherence so the application will be isolated from a complete data store failure.

Distributed queries

Having all the data in the world is meaningless unless there is a way to find the information you need, when you need it. One of the many advantages of In-Memory Data Grids over clustered caches, such as Memcached, is the ability to find data not just by the primary key, but also by executing queries and aggregations against the cache.

Coherence is no exception—it allows you to execute queries and aggregations in parallel, across all the nodes in the cluster. This allows for the efficient processing of large data sets within the grid and enables you to improve aggregation and query performance by simply adding more nodes to the cluster.

In-place and parallel processing

In many situations, you can improve performance enormously if you perform the processing where the data is stored, instead of retrieving the data that needs to be processed. For example, while working with a relational database, you can use bulk update or a stored procedure to update many records without moving any data across the network.

Coherence allows you to achieve the same thing. Instead of retrieving the whole dataset that needs to be processed and iterating over it on a single machine, you can create an entry processor—a class that encapsulates the logic you want to execute for each object in a target dataset. You can then submit an instance of the processor into the cluster, and it will be executed locally on each node. By doing so, you eliminate the need to move a large amount of data across the network. The entry processor itself is typically very small and allows processing to occur in parallel.

The performance benefit of this approach is tremendous. Entry processors, just like distributed queries, execute in parallel across grid nodes. This allows you to improve performance by simply spreading your data across more nodes.

Coherence also provides a grid-enabled implementation of CommonJ Work Manager, which is the basis for JSR-237. This allows you to submit a collection of work items that Coherence will execute in parallel across the grid. Again, the more nodes you have in the grid, the more work items can be executed in parallel, thereby improving the overall performance.

Cache events

In many applications, it is useful to know when a particular piece of data changes. For example, you might need to update a stock price on the screen as it changes, or alert the user if a new workflow task is assigned to them.

The easiest and the most common solution is to periodically poll the server to see if the information on the client needs to be updated. This is essentially what Outlook does when it checks for new e-mail on the POP3 mail server, and you (the user) control how often the polling should happen.

The problem with polling is that the more frequently it occurs, the more load it puts on the server, decreasing its scalability, even if there is no new information to be retrieved.

On the other hand, if the server knows which information you are interested in, it can push that information to you. This is how Outlook works with Exchange Server—when the new mail arrives, the Exchange Server notifies Outlook about this event, and Outlook displays the new message in your inbox.

Coherence allows you to register interest in a specific cache, a specific item, or even a specific subset of the data within the cache using a query. You can specify if you are interested in cache insertions, updates or deletions only, as well as whether you would like to receive the old and the new cache value with the event.

As the events occur in the cluster, your application is notified and can take the appropriate action, without the need to poll the server.

Coherence within the Oracle ecosystem

If you look at Oracle marketing material, you will find out that Coherence is a member of the Oracle Fusion Middleware product suite. However, if you dig a bit deeper, you will find out that it is not just another product in the suite, but a foundation for some of the high-profile initiatives that have been announced by Oracle, such as Oracle WebLogic Application Grid and Complex Event Processing.

Coherence is also the underpinning of the SOA grid—a next-generation SOA platform that David Chappell, vice president and chief technologist for SOA at Oracle, wrote about for The SOA Magazine [SOAGrid1&2].

I believe that over the next few years, we will see Coherence being used more and more as an enabling technology within various Oracle products, because it provides an excellent foundation for fast, scalable, and highly-available solutions.

Coherence usage scenarios

There are many possible uses for