Notice: this Wiki will be going read only early in 2024 and edits will no longer be 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) |
|||
| Line 11: | Line 11: | ||
|example= | |example= | ||
*[[EclipseLink/Examples/JPA/CacheCoordination|How to enable cache coordination]]}} | *[[EclipseLink/Examples/JPA/CacheCoordination|How to enable cache coordination]]}} | ||
| − | =Cache Coordination= | + | =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. | |
| + | |||
| + | EclipseLink can function in any clustered environment. | ||
| + | |||
| + | |||
| + | There are many solutions to caching in a clustered environment, including: | ||
| + | * disable the shared cache | ||
| + | * only cache read-only objects | ||
| + | * set a cache invalidation timeout | ||
| + | * use refreshing on objects/queries when fresh data is required | ||
| + | * use optimistic locking (writes on stale data will fail, and will automatically invalidate the cache) | ||
| + | * using a distributed cache (such as Oracle TopLink Grid with Oracle Coherence) | ||
| + | * using database events to invalidate changed data | ||
| + | * using cache coordination (synchronizing the caches, as discussed in this example) | ||
| + | |||
| + | This example gives an overview of the <i>cache coordination</i> option. | ||
| + | |||
| + | EclipseLink provides a cache coordination feature that enables a set of EclipseLink sessions to synchronize their changes in a distributed network such as an application server cluster. Cache coordination works by each EclipseLink session (ServerSession/persistence unit) on each server in the cluster being able to broadcast notification of transactional object changes to the other EclipseLink sessions in the cluster. EclipseLink supports cache coordination over RMI and JMS. The cache coordination framework is also extensible so other options could be developed. | ||
The need to maintain up-to-date data for all applications is a key design challenge for building a distributed application. The difficulty of this increases as the number of servers within an environment increases. EclipseLink provides a distributed cache coordination feature that ensures data in distributed applications remains current. | The need to maintain up-to-date data for all applications is a key design challenge for building a distributed application. The difficulty of this increases as the number of servers within an environment increases. EclipseLink provides a distributed cache coordination feature that ensures data in distributed applications remains current. | ||
| Line 26: | Line 43: | ||
|next=[[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying|Querying]] | |next=[[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying|Querying]] | ||
|up=[[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching|Caching]] | |up=[[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching|Caching]] | ||
| − | |version=2. | + | |version=2.4 DRAFT}} |
Revision as of 15:15, 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.
EclipseLink can function in any clustered environment.
There are many solutions to caching in a clustered environment, including:
- disable the shared cache
- only cache read-only objects
- set a cache invalidation timeout
- use refreshing on objects/queries when fresh data is required
- use optimistic locking (writes on stale data will fail, and will automatically invalidate the cache)
- using a distributed cache (such as Oracle TopLink Grid with Oracle Coherence)
- using database events to invalidate changed data
- using cache coordination (synchronizing the caches, as discussed in this example)
This example gives an overview of the cache coordination option.
EclipseLink provides a cache coordination feature that enables a set of EclipseLink sessions to synchronize their changes in a distributed network such as an application server cluster. Cache coordination works by each EclipseLink session (ServerSession/persistence unit) on each server in the cluster being able to broadcast notification of transactional object changes to the other EclipseLink sessions in the cluster. EclipseLink supports cache coordination over RMI and JMS. The cache coordination framework is also extensible so other options could be developed.
The need to maintain up-to-date data for all applications is a key design challenge for building a distributed application. The difficulty of this increases as the number of servers within an environment increases. EclipseLink provides a distributed cache coordination feature that ensures data in distributed applications remains current.
Cache coordination reduces the number of optimistic lock exceptions encountered in a distributed architecture, and decreases the number of failed or repeated transactions in an application. However, cache coordination in no way eliminates the need for an effective locking policy. To effectively ensure working with up-to-date data, cache coordination must be used with optimistic or pessimistic locking. We recommend that you use cache coordination with an optimistic locking policy.
You can use cache invalidation to improve cache coordination efficiency.
