Re: J2CA logging/exception handling around SQLException
On Sep 16, 2004, at 3:49 PM, David Blevins wrote: So I'm in the process of cleaning up the OpenEJB itest output as it spits out an excessive amount of stack traces. The exceptions are just SQLExceptions that are being thrown as business method app exceptions. Seems any exceptions (e.g. SQLException) thrown from an RA is being logged on INFO by GeronimoConnectionEventListener. Can't quite tell, but at first glance it looks like it flags the connection handle for removal as well. Is this right and is this what we really want? At the moment this is the correct behavior. The solution is, for each driver, implement an exception sorter that can determine if a particular exception means the connection is no longer usable. Then table doesn't exist exceptions can be distinguished from your db disk just exploded. Unfortunately the jdbc spec has not seen fit to require drivers to distinguish these in a generic fashion. david jencks -David
Re: J2CA logging/exception handling around SQLException
On Thu, Sep 16, 2004 at 04:14:29PM -0700, David Jencks wrote: On Sep 16, 2004, at 3:49 PM, David Blevins wrote: So I'm in the process of cleaning up the OpenEJB itest output as it spits out an excessive amount of stack traces. The exceptions are just SQLExceptions that are being thrown as business method app exceptions. Seems any exceptions (e.g. SQLException) thrown from an RA is being logged on INFO by GeronimoConnectionEventListener. Can't quite tell, but at first glance it looks like it flags the connection handle for removal as well. Is this right and is this what we really want? At the moment this is the correct behavior. The solution is, for each driver, implement an exception sorter that can determine if a particular exception means the connection is no longer usable. Then table doesn't exist exceptions can be distinguished from your db disk just exploded. Unfortunately the jdbc spec has not seen fit to require drivers to distinguish these in a generic fashion. Good idea. Any thoughts on how to actually implement the sorting framework? If we had that in place, the actual act of implementing a sorter and classifying exceptions for each driver is something that could keep many a contributor busy for quite a while. -David
Re: J2CA logging/exception handling around SQLException
OK, so I implemented the framework and entered a tracking issue http://nagoya.apache.org/jira/browse/GERONIMO-306 thanks david jencks On Sep 16, 2004, at 4:53 PM, David Blevins wrote: On Thu, Sep 16, 2004 at 04:14:29PM -0700, David Jencks wrote: On Sep 16, 2004, at 3:49 PM, David Blevins wrote: So I'm in the process of cleaning up the OpenEJB itest output as it spits out an excessive amount of stack traces. The exceptions are just SQLExceptions that are being thrown as business method app exceptions. Seems any exceptions (e.g. SQLException) thrown from an RA is being logged on INFO by GeronimoConnectionEventListener. Can't quite tell, but at first glance it looks like it flags the connection handle for removal as well. Is this right and is this what we really want? At the moment this is the correct behavior. The solution is, for each driver, implement an exception sorter that can determine if a particular exception means the connection is no longer usable. Then table doesn't exist exceptions can be distinguished from your db disk just exploded. Unfortunately the jdbc spec has not seen fit to require drivers to distinguish these in a generic fashion. Good idea. Any thoughts on how to actually implement the sorting framework? If we had that in place, the actual act of implementing a sorter and classifying exceptions for each driver is something that could keep many a contributor busy for quite a while. -David
J2CA logging/exception handling around SQLException
So I'm in the process of cleaning up the OpenEJB itest output as it spits out an excessive amount of stack traces. The exceptions are just SQLExceptions that are being thrown as business method app exceptions. Seems any exceptions (e.g. SQLException) thrown from an RA is being logged on INFO by GeronimoConnectionEventListener. Can't quite tell, but at first glance it looks like it flags the connection handle for removal as well. Is this right and is this what we really want? -David
