> An interesting way that SQLObject tries to get around this issue is to

> have a module attribute on the database connection. So then the
> original DatabaseException from the dbapi module is always at
> conn.module.DatabaseException. But I'm not sure zope.rdb should try
> that.
Indeed, very interesting idea, but I think for Retry and ConflictError 
exceptions it is not a solution here.

In my case, with cxoracleda, there are some oracle errors like:
ORA-03113: End of file in the communication channel

that are 'killing' opened connection. That means this connection is still
opened but no longer useable. Thus it is necessary to close and reopen 
this connection.

I've just changed cxoracleda to catch these specific exceptions
for example in cursor execute method. After catching exception database 
connection is closed and Retry(...) exception raised. 
This will cause that new connection will be created
when new (retried) request will start.

So far it is not possible to use this feature without defeating two bugs 
in Zope3 that are subject of this thread. I had to monkey patch my zope3.

> What does this mean? Are you suggesting implementing the full range of
> dbapi errors in zope.rdb? Or letting the real errors propagate? 
I mean to just let real errors propagate. Backends like
psycopg or cxoracleda are already dbapi aware
so errors they're raising (like ProgrammingError, InterfaceError)
are enough I think.

> One problem with ripping out zope.rdb.interfaces.DatabaseException is
> backwards compatibility and deprecation. I can't think of any sane way
> to do that.
Right, so possibly first step should be to at last let Retry
and ConflictError errors propagate.

Maciej Wisniowski
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to