Skip to Main Content

Integration

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Failover with Distributed Cache Synchronization

413051Jan 29 2004 — edited Feb 12 2004
I am trying to work out how to deploy an application using TopLink in an Oracle Application Server 9.0.4 (10g) cluster. I am currently working with OC4J standalone 9.0.4 (I am working out the TopLink configuration with OC4J standalone for simplicity and will move on to the full app server once I have worked out the TopLink issues).

My requirements are:
1) When one OC4J instance goes down the other instance(s) must still continue to work.
2) When an OC4J instance that has goes down and is restarted then TopLink distributed cache synchronisation must continue to work.

I have two machines, let's call them A and B.

When I use the JMSClusteringService, with the JMS server running on machine A, then if I stop and restart OC4J on B everything is OK. When I stop OC4J on A then the OC4J instance on B continues to work (so requirement 1 is satisfied). However when I restart OC4J on A then distributed cache synchronization does not work i.e. none of the updates I make on either machine get propagated to the other, so requirement 2 is not met.

When I use the RMIJNDIClusteringService, with the RMI registry on machine A, then if I stop and restart OC4J on B everything is OK (as before). When I stop OC4J on A then I get exceptions when I try to use the OC4J instance on B (see the end of this post for an example), so requirement 1 is not met. When I restart OC4J on A then the instance on B starts work again, so requirement 1 is met.

Is there any way I can configure distributed cache synchronization so that both 1 and 2 are met?

Thanks,

Francis

Caused by: com.evermind.server.rmi.RMIConnectionException: Connection reset
at com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:50)
at com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:22)
at __Proxy2.create(Unknown Source)
at uk.co.corelogic.framework.person.struts.AmendPersonPersonalInitAction.fwPerform(AmendPersonPersonalInitAction.java:107)
at uk.co.corelogic.framework.common.struts.FrameworkAction.perform(FrameworkAction.java:224)
... 12 more
com.evermind.server.rmi.RMIConnectionException: Connection reset
at com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:50)
at com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:22)
at __Proxy2.create(Unknown Source)
at uk.co.corelogic.framework.person.struts.AmendPersonPersonalInitAction.fwPerform(AmendPersonPersonalInitAction.java:107)
at uk.co.corelogic.framework.common.struts.FrameworkAction.perform(FrameworkAction.java:224)
at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1787)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:492)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:765)
at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317)
at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
at java.lang.Thread.run(Thread.java:534)

Comments

mkeith
Hi Francis,

It appears that my first reply was lost, so will re-post.

When using JMS the reconnect policy should reconnect to the topic, but only if the should-remove-connection-on-error setting in sessions.xml is false. Alternatively you can set it directly on the CacheSynchronizationManager by invoking setShouldRemoveConnectionOnError(false).

Note that for RMIJNDI cache sync the RMI Registry is not used. It may be that whatever type of object you are using does not support transparent failover so you may need to reacquire a stub (e.g. for vanilla RMI objects).

HTH,
-Mike
413051
I am already setting should-remove-connection-on-error to false. Should this make cache synchronization continue to work after the OC4J instance running the JMS server has been restarted? Here is the relevant section of my sessions.xml (for JMS):
<cache-synchronization-manager>
<clustering-service>oracle.toplink.remote.jms.JMSClusteringService</clustering-service>
<should-remove-connection-on-error>false</should-remove-connection-on-error>
<jms-topic-connection-factory-name>jms/TopicConnectionFactory</jms-topic-connection-factory-name>
<jms-topic-name>jms/TopLinkCacheSyncTopic</jms-topic-name>
</cache-synchronization-manager>

I don't really understand your last paragraph... What do I have to do to make my objects support transparent failover? All of the objects that I am using TopLink to persist are simple Serializable JavaBeans.

Francis
mkeith
Hi Francis,

It appears as if by default the reconnection policy does not reconnect, so you will have to subclass the JMSDistributedSessionReconnectPolicy clas and set it on the clustering service (e.g. clusteringService.setReconnectPolicy(new MyReconnectPolicy())). You will want to override the reconnect(RemoteConnection) method to call clusteringService.createRemoteConnection(). Note that you wil have to set the clustering service on your policy instance when you set the policy so that you can access the service from within the reconnect callback. I would also recommend setting the logging to log-debug so that you can see what is happening.

For the RMI, it looks like from your stack trace an RMI object is broken. If you are using JavaBeans then it is is not a TopLink-managed one but it won't be affected or fixed by cache sync.

-Mike
1 - 3
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Mar 11 2004
Added on Jan 29 2004
3 comments
296 views