Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/UserGuide/JPA/Basic JPA Development/Caching/Coordination"
(→Cache Coordination) |
(→Clustering Cache Coordination) |
||
| Line 14: | Line 14: | ||
An application cluster is a set of middle tier server machines or VMs servicing requests for a single application, or set of applications. Multiple servers are used to increase the scalability of the application and/or to provide fault tolerance and high availability. Typically the same application will be deployed to all of the servers in the cluster and application requests will be load balanced across the set of servers. The application cluster will access a single database, or a database cluster. An application cluster may allow new servers to be added to increase scalability, and for servers to be removed such as updates and servicing. | An application cluster is a set of middle tier server machines or VMs servicing requests for a single application, or set of applications. Multiple servers are used to increase the scalability of the application and/or to provide fault tolerance and high availability. Typically the same application will be deployed to all of the servers in the cluster and application requests will be load balanced across the set of servers. The application cluster will access a single database, or a database cluster. An application cluster may allow new servers to be added to increase scalability, and for servers to be removed such as updates and servicing. | ||
| − | + | Application clusters can consist of Java EE servers, web containers, or Java server applications. | |
| + | EclipseLink can function in any clustered environment. The main issue in a clustered environment is utilizing a shared persistence unit (L2) cache. If you are using a shared cache (enabled by default in EclipseLink), then each server will maintain its own cache, and each caches data can get out of sync with the other servers and the database. | ||
| − | + | EclipseLink provides cache coordination in a clustered environment to ensure the servers caches are is sync. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | There are also many other solutions to caching in a clustered environment, including: | |
| + | * Disable the shared cache (through setting <code>@Cacheable(false)</code>, or <code>@Cache(isolation=ISOLATED)</code>). | ||
| + | * Only cache read-only objects. | ||
| + | * Set a cache invalidation timeout to reduce stale data. | ||
| + | * Use refreshing on objects/queries when fresh data is required. | ||
| + | * Use optimistic locking to ensure write consistency (writes on stale data will fail, and will automatically invalidate the cache). | ||
| + | * Use a distributed cache (such as Oracle TopLink Grid's integration of EclipseLink with Oracle Coherence). | ||
| + | * Use database events to invalidate changed data in the cache (such as EclipseLink' support for Oracle DCN/QCN). | ||
| + | * Use cache coordination in EclipseLink (discussed in this section. | ||
| − | + | Cache coordination enables a set of persistence units deployed to different servers in the cluster (or on the same server) to synchronize their changes. Cache coordination works by each persistence unit on each server in the cluster being able to broadcast notification of transactional object changes to the other persistence units in the cluster. EclipseLink supports cache coordination over RMI and JMS. The cache coordination framework is also extensible so other options could be developed. | |
| − | + | We recommend that you use cache coordination with an [[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Locking/Optimistic_Locking|optimistic locking policy]]. | |
| − | + | ||
| − | + | ||
You can use [[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Expiration|cache invalidation]] to improve cache coordination efficiency. | You can use [[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Expiration|cache invalidation]] to improve cache coordination efficiency. | ||
| − | |||
Revision as of 15:29, 17 May 2012
EclipseLink JPA
| EclipseLink | |
| Website | |
| Download | |
| Community | |
| Mailing List • Forums • IRC • mattermost | |
| Issues | |
| Open • Help Wanted • Bug Day | |
| Contribute | |
| Browse Source |
Key API
Examples
Clustering Cache Coordination
An application cluster is a set of middle tier server machines or VMs servicing requests for a single application, or set of applications. Multiple servers are used to increase the scalability of the application and/or to provide fault tolerance and high availability. Typically the same application will be deployed to all of the servers in the cluster and application requests will be load balanced across the set of servers. The application cluster will access a single database, or a database cluster. An application cluster may allow new servers to be added to increase scalability, and for servers to be removed such as updates and servicing.
Application clusters can consist of Java EE servers, web containers, or Java server applications.
EclipseLink can function in any clustered environment. The main issue in a clustered environment is utilizing a shared persistence unit (L2) cache. If you are using a shared cache (enabled by default in EclipseLink), then each server will maintain its own cache, and each caches data can get out of sync with the other servers and the database.
EclipseLink provides cache coordination in a clustered environment to ensure the servers caches are is sync.
There are also many other solutions to caching in a clustered environment, including:
- Disable the shared cache (through setting
@Cacheable(false), or@Cache(isolation=ISOLATED)). - Only cache read-only objects.
- Set a cache invalidation timeout to reduce stale data.
- Use refreshing on objects/queries when fresh data is required.
- Use optimistic locking to ensure write consistency (writes on stale data will fail, and will automatically invalidate the cache).
- Use a distributed cache (such as Oracle TopLink Grid's integration of EclipseLink with Oracle Coherence).
- Use database events to invalidate changed data in the cache (such as EclipseLink' support for Oracle DCN/QCN).
- Use cache coordination in EclipseLink (discussed in this section.
Cache coordination enables a set of persistence units deployed to different servers in the cluster (or on the same server) to synchronize their changes. Cache coordination works by each persistence unit on each server in the cluster being able to broadcast notification of transactional object changes to the other persistence units in the cluster. EclipseLink supports cache coordination over RMI and JMS. The cache coordination framework is also extensible so other options could be developed.
We recommend that you use cache coordination with an optimistic locking policy.
You can use cache invalidation to improve cache coordination efficiency.
