2 Replies Latest reply on Aug 2, 2007 6:33 AM by Douglas Fraser

    Performing cache operations while in a catch() section

    Douglas Fraser Newbie

      Hi all,

      the application I have written, when handling exceptions in one part, performs a cache operation (setting a node's value) to inform the other members of the cluster as to what is happening with a resource shared amongst the cluster.

      everything looks and acts fine, then a minute or two later after the dust has settled, a warning pops up in server.log

      17:56:19,454 WARN [TreeCache] status is 1 (not ACTIVE or PREPARING); returning null)
      at org.jboss.cache.TreeCache.getCurrentTransaction(TreeCache.java:5805)
      at org.jboss.cache.TreeCache.getCurrentTransaction(TreeCache.java:5775)
      at org.jboss.cache.TreeCache.put(TreeCache.java:3831)
      at sun.reflect.GeneratedMethodAccessor116.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
      at $Proxy56.put(Unknown Source)
      at com.mec.management.mbeans.TreeCacheFacade.setValue(TreeCacheFacade.java:296)

      [and so on]

      there are a few of these - it seems every cache related operation done while handling an exception has problems. there is a transaction timeout message before all this

      17:55:17,034 WARN [TransactionImpl] Transaction TransactionImpl:XidImpl[FormatId=257, GlobalId=xbod-app01.xb-online.com/37, BranchQual=, localId=37] timed out. status=STATUS_ACTIVE

      the cache is in REPL_SYNC mode, but I don't know what else to say as I'm not sure what else is important

      I am sensing that this general idea of using the cache to update information within catch() blocks is not a good idea. I am lost as how to deal with this - is there some general principles I should follow or should I move the cache operation out of the exception handling all together (and how to?)?

      yeah, they're only warnings but they look important. If someone could possibly explain what is going on, I would greatly appreciate it


        • 1. Re: Performing cache operations while in a catch() section
          Manik Surtani Master

          Does your code in the try block fail due to a transaction failing?

          What seems to be the problem is that your cache participates in your transaction (perhaps a call to the cache in your try block), the tx fails, and then you attempt to try more operations on the cache in your catch block.

          If the cache operation in catch doesn't need to be transactional, you could suspend the transaction before your cache call, and then resume it afterwards.

          • 2. Re: Performing cache operations while in a catch() section
            Douglas Fraser Newbie

            yes, that is sort of it - I figured it out just before you replied. the entire operation is wrapped in a transaction (it's processing a MDB message) and communication with another system fails, so the code throws an exception to trigger the catch section in the onMessage() method that acts as a general point for rolling back operations. In that catch(), the cache operation happens - and the cache is set up to use transactions. then the overall transaction gets rolled back, so another node could retry processing the message.

            so since the overall transaction gets rolled back, transactions within won't complete properly.

            so I need to look at whether all the cache operations really need to be transactional (can I suspend the use of transactions in the cache individually?) or figure out how to suspend the overall transaction (but the container is doing all that work right now, so I'd have to get into the guts of things... that does not sound appetizing)