Scaling JPA applications or deploying them to flexible resources can be a challenge. How do I scale, what is the impact on caching and how can I reuse resources? In this talk we will work through these challenges with real examples using JPA and EclipseLink. Exploring where and when to apply best practices and the many features available for caching, scalability, resource sharing and elastic deployments.
Why Teams call analytics are critical to your entire business
Climbing the beanstalk
1. Climbing the Beanstalk Scaling Java Persistence to the Cloud Gordon Yorke JPA 2.1 Expert Group EclipseLink Architecture Council
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Editor's Notes
Australia
The Grid Read configuration a little different than the Grid Cache configuration in that rather than just caching objects in Coherence we start to execute queries for those objects against Coherence. This is for both primary key and non-primary key queries. If you noticed in the last configuration, the Grid Cache configuration, we were executing primary key queries against Coherence. In the Grid Read configuration we redirect all, both primary and non-primary key queries, to Coherence. This configuration is useful for entities is that have to be highly available. Being in Coherence they can be found a very rapidly without having to do a database round-trip. This is also useful for entities that have to have their changes written synchronously to the database. In this configuration EclipseLink is doing all the writing. Therefore you get the advantage of batch writing, JTA transaction integration, and other write optimizations and features. And you're also guaranteed that your database is correct. Each transaction runs, the database is updated synchronously, and once the transaction has committed Coherence is updated. It is possible for database failures to occur in this configuration, for example optimistic lock exceptions. If a failure does occur the transaction roles back and the changes are not applied to Coherence. So this configuration is suitable when database transaction failures can occur. The characteristics of this configuration include that the database is always correct – the database is committed before the cache is updated. All the write performance features of EclipseLink are available. But because all reads are being redirected into the grid you get the benefit of high-performance parallel query processing. And you can optionally configure a CacheLoader so that primary key queries against Coherence can load an object from the database if it's not in the grid.
Grid Entity is a further incremental change on top of the previous Grid Read configuration. In this case all the reads and all the writes are executed against Coherence. In this configuration, Coherence is effectively the system of record. All the queries are redirected to it instead of the database. You may have a database behind Coherence but EclipseLink will treat Coherence as the data source. This configuration makes sense for Entities that need to be highly available and can be written asynchronously to a backing database through a CacheStore. With Coherence write behind changes can be flushed the database asynchronously at intervals. The database will not be up-to-date until Coherence flushes any pending writes. So if you're using right behind, in the period between the EclipseLink transaction commit and the flush of those changes the database will be out of sync with the cache so third-party applications that access the database may read stale data. This is nothing new for Coherence developers working with a database and using write behind. This configuration cannot benefit from all of the EclipseLink write features optimizations other available using the other two configurations.
![EclipseLink Project ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)