Ok. Thanks. I'll redefine the execute method in my subclass. I'm using a connection pool, so that would be the way to go.
On Fri, 5 Sep 2003 14:23:15 -0700, Charles Hudak wrote: >Actually, if you look at the code, the connection is closed in the finalize >method, not after every call to the execute method so the connection will >only be closed when the object is GC'd. The code is actually fairly fragile >in that if the connection times out (and is summarilly closed), the appender >will never reopen the connection and all further log events will fail. > >From the comments, it looks like JDBCAppender is a SIMPLE implementation >(read reference implementation) that is designed to be subclassed to provide >better functionality (e.g. using connection pooled DataSources in a webapp). > >-----Original Message----- >From: Milind Rao [mailto:[EMAIL PROTECTED] >Sent: Friday, September 05, 2003 14:09 >To: [EMAIL PROTECTED] >Subject: Bug in JDBCAppender > > >There is a bug in JDBCAppender's execute method. If there is a >SQLException, the connection is not >closed. The best place to close a connection/statement is in "finally". >What's happening now, is >I'm getting a connection leak every time an SQL exception happens. > >BTW, the log also gets lost. Shouldn't the fallback handler kick in here? > > > >Regards >Milind > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > Regards Milind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
