Use eclipselink.cache.coordination.propagate-asynchronously
to specify if the coordination broadcast should occur asynchronously with the committing thread
property configures cache coordination for a clustered environment. Set if the coordination broadcast should occur asynchronously with the committing thread. This means the coordination will be complete before the thread returns from the commit of the transaction.
Table 5-11 describes this persistence property's values.
Table 5-11 Valid Values for cache.coordination.propagate-asynchronously
Value | Description |
---|---|
|
(Default) TopLink will broadcast asynchronously. The coordination will be complete before the thread returns from the committing the transaction. |
|
TopLink will broadcast synchronously. |
JMS cache coordination is always asynchronous, regardless of this setting.
By default, RMI cache coordination is asynchronous. Use synchronous (eclipselink.cache.coordination.propagate-asynchronously
= false
) to ensure that all servers are updated before the request returns.
Example 5-5 shows how to use this property in the persistence.xml
file.
Example 5-5 Using cache.coordination.propagate-asynchronously in persistence.xml
<property name="eclipselink.cache.coordination.propagate-asynchronously" value="false" />
For more information, see:
"Cache Coordination" in Understanding Oracle TopLink
"Scaling TopLink Applications in Clusters" in Solutions Guide for Oracle TopLink