On Sun, 2004-07-25 at 12:41, Itamar Shtull-Trauring wrote:

On Sun, 2004-07-25 at 13:28, Christopher Armstrong wrote:

...

I've been trying to think of a way to at least work around this on a per-app basis -- mine is using psycopg. It just raises either a ProgrammingError or an OperationalError on cursor.execute. The brightest idea we've come up with is to reconnect after N (~ 3) consecutive errors.

Any other ideas?

Upon errors, test a command that will always work ("SELECT 1"), if that fails reconnect.

The test command should be easily overridden. You would think all db's would support 'select 1', but they don't. On Oracle, for example, you would need 'select 1 from dual'. dave

On Sun, 2004-07-25 at 15:49, Christopher Armstrong wrote:

Dave Peticolas wrote:

...

On Sun, 2004-07-25 at 12:41, Itamar Shtull-Trauring wrote:

...

On Sun, 2004-07-25 at 13:28, Christopher Armstrong wrote:

...

I've been trying to think of a way to at least work around this on a per-app basis -- mine is using psycopg. It just raises either a ProgrammingError or an OperationalError on cursor.execute. The brightest idea we've come up with is to reconnect after N (~ 3) consecutive errors.

Any other ideas?

Upon errors, test a command that will always work ("SELECT 1"), if that fails reconnect.

The test command should be easily overridden. You would think all db's would support 'select 1', but they don't. On Oracle, for example, you would need 'select 1 from dual'.

Hmm, but can we put this functionality in adbapi? Maybe with an __init__ flag, cp_detectConnectionLost?

Yeah, that shouldn't be too hard. dave

On Sun, 2004-07-25 at 12:41, Itamar Shtull-Trauring wrote:

On Sun, 2004-07-25 at 13:28, Christopher Armstrong wrote:

...

I've been trying to think of a way to at least work around this on a per-app basis -- mine is using psycopg. It just raises either a ProgrammingError or an OperationalError on cursor.execute. The brightest idea we've come up with is to reconnect after N (~ 3) consecutive errors.

Any other ideas?

Upon errors, test a command that will always work ("SELECT 1"), if that fails reconnect.

The test command should be easily overridden. You would think all db's would support 'select 1', but they don't. On Oracle, for example, you would need 'select 1 from dual'. dave

On Sun, 2004-07-25 at 15:49, Christopher Armstrong wrote:

Dave Peticolas wrote:

...

On Sun, 2004-07-25 at 12:41, Itamar Shtull-Trauring wrote:

...

On Sun, 2004-07-25 at 13:28, Christopher Armstrong wrote:

...

I've been trying to think of a way to at least work around this on a per-app basis -- mine is using psycopg. It just raises either a ProgrammingError or an OperationalError on cursor.execute. The brightest idea we've come up with is to reconnect after N (~ 3) consecutive errors.

Any other ideas?

Upon errors, test a command that will always work ("SELECT 1"), if that fails reconnect.

The test command should be easily overridden. You would think all db's would support 'select 1', but they don't. On Oracle, for example, you would need 'select 1 from dual'.

Hmm, but can we put this functionality in adbapi? Maybe with an __init__ flag, cp_detectConnectionLost?

Yeah, that shouldn't be too hard. dave