re: "But then I thought it unlikely tham someone restarts the database and expects connection objects to persist."
We don't have a problem getting rid of a connection object and instancing a new one -- we're just trying to be 100% sure we have the correct rules about when to do this. It would be very nice if we could always distinguish connection problems from SQL errors -- it really helps narrow down quickly where a customer's problem is. After all, in a long-lived process scenario, the dbm/dba might restart a server for maintenance on a separate box. And we want to recover cleanly and simply in this case and other cases like unexpected network troubles etc... ----- Original Message ----- From: "Dittmar, Daniel" <[EMAIL PROTECTED]> To: "'Jeff Robbins'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, February 28, 2003 12:21 PM Subject: RE: python connection object in a long-lived process > > >>> > 1) once you instance a connection object, is it usable for the lifetime of your python process or are there circumstances where you must instance a new one to reconnect to the database? > <<< > > When a session gets disconnected (timeout, database down), the driver tries to reconnect. If this fails, the connection object is no longer usable. I could check what happens if the driver tries a reconnect on every method call in this state. > > >>> > 2) if the connection object is usable for the lifetime of your python process, are there (or could there be) ways to monitor and control its state? E.g. force it to try to reconnect right away, configure its retry timer, inquire or ping as to its state, etc... > <<< > > A ping method might be useful. You can achieve the same effect by sending an arbitrary string to the database and catching syntax errors only. But there does exists a special command in the network protocol, and it should be used for this. > > Note that even when the driver is able to reconnect, it will still throw an exception. This is reasanable when a transaction has been broken. It is less so when the last command was a commit or rollback. This is a flaw in the implementation and I hope I can fix it sometime. > > >>> > 3) if the connection object is not usable for the lifetime of your python process, what error codes indicate this definitively? > <<< > > I would have thought that any such error would raise a Communication error (sapdb.sql) or OperationalError (sapdb.dbapi). But it seems that when the kernel is in admin mode, the driver gets a regular SQL error and passes this back to the client. > SQLM.en: ENG -8000 SERVERDB must be restarted > SQLM.en: ENG -4008 Unknown user name/password combination > > I admit the latter is unlikely. But then I thought it unlikely tham someone restarts the database and expects connection objects to persist. > > Daniel Dittmar > > -- > Daniel Dittmar > SAP DB, SAP Labs Berlin > [EMAIL PROTECTED] > http://www.sapdb.org/ > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
