|
| Re: Clustering Jboss with Eclipselink [message #628638 is a reply to message #560093] |
Thu, 23 September 2010 13:53   |
|
I am working on an example of how to configure cache coordination in a clustered environment, you can see the current draft here,
http://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordi nation
it uses Oracle WebLogic, but should be applicable to JBoss as well. You can use either JMS or RMI, for JMS you just need to create a Topic, for RMI if JBoss replicates JNDI you should only have to set the protocol to RMI.
EclipseLink does not integrate with the JBoss data cache, and EclipseLink uses an object cache, which is more complex than a data cache, so integrating with the JBoss cache would loose functionality.
EclipseLink's cache coordination does not support JGroups, but is plug-able, so you could implement your own JGroups transport. This should be fairly easy to do, as we did have JGroups support for OC4J at one point, so the hooks are still there. There is an existing enhancement request to support JGroups, you could vote for this.
EclipseLink does provide an API for integration with a third party cache. This is used by the Oracle TopLink integration with Oracle Coherence.
James : Wiki : Book : Blog : Twitter
|
|
|
|
|
|
| Re: Clustering Jboss with Eclipselink [message #629263 is a reply to message #560093] |
Mon, 27 September 2010 15:55 |
|
Generally it is a good idea to have server affinity enabled to ensure a client's session uses the same server. This avoids excessive synchronization and replication costs.
EclipseLink supports both asynchronous and synchronous cache coordination. asynchronous, as waiting for all the servers to be updated is normally not desirable. There is a slight lag time for the asynchronous coordination to occur.
If you cannot enable server affinity in your application server, and your client is bouncing from server to server, then you may wish to enable synchronous depending on how likely the same client getting stale data is.
In general optimistic locking should be used to avoid an update using stale data, this is true even in a single server environment.
If you really need to ensure a read never gets stale data then you should consider disabling the shared cache (but of coarse this still will not guarantee this, as once you read the data it could be updated by another user, unless you acquire a pessimistic lock (and so does everyone else)).
James : Wiki : Book : Blog : Twitter
|
|
|
Powered by
FUDForum. Page generated in 0.12701 seconds
] 
Search
Help
Register
Login
Home
