Cache Synchronization Exception Handling

Question

I am setting up cache synchronization on WebLogic using JMS. I am looking into writing an exception handler to handle cache synchronization exceptions. The following statement in the documentation caught my attention:
“As mentioned above, the TopLink cache does not begin the merge or update process until the database transaction has already been committed. This is quite beneficial in that it avoids letting uncommitted data into the shared cache, but should be recognized where transactional synchronization is considered. In cases where a merge may have failed there is no way to roll back the changes made to the database (although it is questionable whether this would be a good idea in any case). As a consequence, failures during remote merging can leave the cache in an inconsistent state. This makes it important to handle any errors that occur by performing cache normalization actions, such as resetting the cache, or even the server.”
Suppose we have two app server instances, A and B. Instance A commits a change and sends the update notification to instance B. The merge fails on instance B with an optimistic lock exception.
- I assume that a CacheSynchronizationException will be thrown. Will it be thrown on instance A, B, or both?
- At this point which cache is inconsistent; A, B, or both?
- The documentation suggests resetting the cache, but this seems a rather severe way of dealing with the problem. Is it feasible / effective to just refresh the objects in the change set of the CacheSynchronizationException?
This is a simple exception handler. On receiving a CacheSynchronizationException it resets the cache and re-throws the exception.
class ToplinkExceptionHandler implements ExceptionHandler{
     public Object handleException(RuntimeException exception) throws DatabaseException{
          if(exception instanceof CacheSynchronizationException){){
               myServerSession.initializeAllIdentityMaps();
               throw exception;
          }else{
               throw exception;
- Is this approach effective?
- Once the cache is reset should the exception be re-thrown or should I consider it handled and swallow it? If I do swallow it what should the method return?
Any advice would be appreciated.

Answer 1

I had to fix a few errors (in our code) before getting it working. Since I have multiple sessions, I had to specify different multicast ports (actually I used a different multicast address itself) for each of the sessions. I was not setting the announcement delay on one of the sesssions and that was why it was announcing immediately upon coming up. Also I had to explicitly set asynchronous to false because it is true by default.
BTW, we are not using CMP (entity beans) rather Java Objects. Our deployment has two Apache/Tomcat machines and two WebLogic machines. The WebLogic servers are in a round-robin cluster. The cache synchronization seems to be working fine for this configuration.
Thanks.
Anand R