atom feed7 messages in org.codehaus.esper.dev[esper-dev] [jira] Issue Comment Edit...
FromSent OnAttachments
Thomas Bernhardt (JIRA)Oct 20, 2008 12:09 pm 
Thomas Bernhardt (JIRA)Oct 20, 2008 12:09 pm 
Alexandre Vasseur (JIRA)Oct 24, 2008 1:30 pm 
Alexandre Vasseur (JIRA)Oct 24, 2008 1:30 pm 
Thomas Bernhardt (JIRA)Nov 3, 2008 2:17 pm 
Thomas Bernhardt (JIRA)Nov 3, 2008 2:17 pm 
Thomas Bernhardt (JIRA)Nov 8, 2008 7:47 pm 
Subject:[esper-dev] [jira] Issue Comment Edited: (ESPER-297) Detect dead database connection and retry
From:Alexandre Vasseur (JIRA) (ji@codehaus.org)
Date:Oct 24, 2008 1:30:21 pm
List:org.codehaus.esper.dev

[
http://jira.codehaus.org/browse/ESPER-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151848#action_151848
]

avasseur edited comment on ESPER-297 at 10/24/08 3:30 PM:

-------------------------------------------------------------------

I think the current behavior has its roots in the ConnectionCache. I assume
closing the connection instead of keeping it in a cache would have some impact. If we compare to app server, there is usually a connection pool (not cache),
with sanitizing logic that can be configured in many ways among: - test on reserve (thru sql select * from dual kind of query or custom one
provided) - test on release - trust grace period (if it was tested no longer than x, then don't test) - background testing - min/max pool size and idle timeout - waiter delay - etc I believe that would be the ideal design target. See f.e.
http://e-docs.bea.com/wls/docs100/jdbc_admin/jdbc_datasources.html#wp1195919 for
some example from the app server land. Or also Apache commons DBCP http://commons.apache.org/dbcp/configuration.html
that does similar things and would be easy to integrate for an end user (not
sure it is a good choice to end up as core esper dependency - see the release
history) By adding this, there is a need for richer configuration (api and xml) as well.

was (Author: avasseur): I think the current behavior has its roots in the ConnectionCache. I assume
closing the connection instead of keeping it in a cache would have some impact. If we compare to app server, there is usually a connection pool (not cache),
with sanitizing logic that can be configured in many ways among: - test on reserve (thru sql select * from dual kind of query or custom one
provided) - test on release - trust grace period (if it was tested no longer than x, then don't test) - background testing - min/max pool size and idle timeout - waiter delay - etc I believe that would be the ideal design target. See f.e.
http://e-docs.bea.com/wls/docs100/jdbc_admin/jdbc_datasources.html#wp1195919 for
some example from the app server land. Or also Apache commons DBCP that does similar things and would be easy to
integrate for an end user (not sure it is a good choice to end up as core esper
dependency - see the release history) By adding this, there is a need for richer configuration (api and xml) as well.

Detect dead database connection and retry

-----------------------------------------

Key: ESPER-297 URL: http://jira.codehaus.org/browse/ESPER-297 Project: Esper Issue Type: Improvement Affects Versions: 2.2 Reporter: Thomas Bernhardt Priority: Minor Fix For: 2.3

A user has reported that she is using a join with an SQL result from an Oracle
database connection, and that connection is shaky. In order to create a new connection when the current one dies, she would like to
have a simpler way to handle errors. The current way of using a DataSource provided by an application server, or from
any JNDI directory, is awkward.