You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2004/09/17 00:49:06 UTC
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
Re: J2CA logging/exception handling around SQLException
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: J2CA logging/exception handling around SQLException
Posted by David Blevins <da...@visi.com>.
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
Posted by David Jencks <dj...@gluecode.com>.
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
>