3 Replies Latest reply on Aug 14, 2007 1:39 PM by Adrian Dimulescu

    db error : exception handler cannot be loaded and infinite l

    Adrian Dimulescu Newbie


      It happens that my appserver's datasource become unavailable (no more connections etc.) That should not happen, of course, but shit happens. In this case, a runtime exception will occur in the middle of the process. I have an exception handler pointing to an "OnErrorAction" that is supposed to handle the exception.

      In order to handle the exception, ProcessClassLoader tries to load the error handler class. It cannot because the datasource has just crashed. The not being able to load the class generates another exception that has to be caught by the same exception handler. There is an infinite loop there.

      If my understaning of what happens is right, I think the exception handlers should be loaded first and get cached. In fact, I think all classes that ProcessClassLoader may load should be loaded in memory just to be on the safe side.

      Best regards,

        • 1. Re: db error : exception handler cannot be loaded and infini
          Ronald van Kuijk Master

          he, why not load the whole internet to be safe ;-)... but seriously, this error should be handled in a more appropriate manner, but not by just loading things in advance..

          • 2. Re: db error : exception handler cannot be loaded and infini
            Ronald van Kuijk Master

            whoops... pressed the wrong button....

            ....in advance without thinking more thoroughly about the consequences e.g. what if the errorhandler was loaded in advance, but wants to write a processvariable in the db then you have a loop again...

            • 3. Re: db error : exception handler cannot be loaded and infini
              Adrian Dimulescu Newbie

              Well, the error handler can do its job inside a try-catch(Exception) and be sure that nothing escapes it. That's what I personally do, in fact.

              But if the error handler itself is not available, then it is more like a "framework" problem. Moreover, the exception handler is typically loaded when there IS a problem. One of possible problems may be a database problem, irrespective of how much effort has been put into the correct configuration of the application.

              Indeed, loading all classes in advance may be overkill for processes with lots of custom actions and code deployed in the process archive (although I understand deploying lots of code into the database is actually discouraged and I understand why) -- But, leaving ordinary classes aside, how many exception handlers can there be ?

              Eager loading or not -- the actual big problem that occurs on general db failure is the infinite loop. Indeed, all that an already-loaded exception handler can do on general db failure is log stuff to log4j but anyway things get logged. So the only real problem remains the loop.