Thread: [SQLObject] mysql connection losses
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Victor Ng <vn...@ma...> - 2004-03-17 16:14:30
|
I'm getting the following error in my application using SQLObject 0.5.1 and MySQL. Any ideas on how to work around this problem? I'd like to be able to set an expiry option on the connection pool so that connections will only be used 'N' number of times before they get closed and discarded. 16912 File "/usr/local/lib/python2.3/site-packages/SQLObject/Join.py", line 104, in performJoin 16913 inst.id) 16914 File "/usr/local/lib/python2.3/site-packages/SQLObject/DBConnection.py", line 328, in _SO_selectJoin 16915 return self.queryAll("SELECT %s FROM %s WHERE %s = %s" % 16916 File "/usr/local/lib/python2.3/site-packages/SQLObject/DBConnection.py", line 136, in queryAll 16917 return self._runWithConnection(self._queryAll, s) 16918 File "/usr/local/lib/python2.3/site-packages/SQLObject/DBConnection.py", line 72, in _runWithConnection 16919 val = meth(conn, *args) 16920 File "/usr/local/lib/python2.3/site-packages/SQLObject/DBConnection.py", line 129, in _queryAll 16921 c.execute(s) 16922 File "/usr/local/lib/python2.3/site-packages/MySQLdb/cursors.py", line 61, in execute 16923 r = self._query(query) 16924 File "/usr/local/lib/python2.3/site-packages/MySQLdb/cursors.py", line 168, in _query 16925 rowcount = self._BaseCursor__do_query(q) 16926 File "/usr/local/lib/python2.3/site-packages/MySQLdb/cursors.py", line 112, in __do_query 16927 db.query(q) 16928 OperationalError: (2013, 'Lost connection to MySQL server during query') |
From: Frank B. <fb...@fo...> - 2004-03-17 20:58:46
|
Hallo, Victor Ng hat gesagt: // Victor Ng wrote: > I'm getting the following error in my application using SQLObject 0.5.1 > and MySQL. > > Any ideas on how to work around this problem? Install and use PostgreSQL. Sorry to say this, but at least I was fighting and googling this problem for weeks to no avail at all, I tried various patches to python-mysql, nothing helped. As my project was nearing release time, I switched to PostgreSQL the night before deadline which finally fixed all my problems. I don't know who to blame, but I don't blame me anymore. ;) No I can do python progamming again instead of struggling with a (to me) unsolvable problem. ciao -- Frank Barknecht _ ______footils.org__ |
From: Victor Ng <vn...@sy...> - 2004-03-18 00:54:39
|
Grrr.... This is really annoying. I'm using MySQL for this one database because Postgresql seems to have broken the error handling between 7.2 and 7.4. I've got 7.2 on my production server and 7.4 on my laptop right now. Trying to connect with psycopg on a 7.4 client to a 7.4 server doesn't work properly so I can't connect to Postgres from my laptop which is running pgsql 7.4. I can only connect remotely to the Postgres 7.2 database using a lone Linux machine sitting in the corner of the room. I've tried switching to a Unix Domain socket from a TCP connection in MySQLdb and I still get errors (different errors - but errors nonetheless). I hate MySQL. Gah. Thanks for the help - at least I don't feel completely stupid. I'll be switching back to Postgresql. vic On Mar 17, 2004, at 3:01 PM, Frank Barknecht wrote: > Hallo, > Victor Ng hat gesagt: // Victor Ng wrote: > >> I'm getting the following error in my application using SQLObject >> 0.5.1 >> and MySQL. >> >> Any ideas on how to work around this problem? > > Install and use PostgreSQL. > > Sorry to say this, but at least I was fighting and googling this > problem for weeks to no avail at all, I tried various patches to > python-mysql, nothing helped. As my project was nearing release time, > I switched to PostgreSQL the night before deadline which finally fixed > all my problems. I don't know who to blame, but I don't blame me > anymore. ;) > > No I can do python progamming again instead of struggling with a (to > me) unsolvable problem. > > ciao > -- > Frank Barknecht _ ______footils.org__ > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > > --- "We are what we repeatedly do. Excellence then, is not an act. It is a habit." - Aristotle |
From: David W. <da...@su...> - 2004-03-18 02:18:08
|
Victor, > I'm getting the following error in my application using SQLObject 0.5.1 > and MySQL. > > Any ideas on how to work around this problem? I'd like to be able to > set an expiry option on the connection pool so that connections will > only be used 'N' number of times before they get closed and discarded. Our Java connection pool tests every connection before it gives it to the client (by setting autocommit). If the test fails then the connection is removed from the pool and the next connection (or if required a new connection) is returned. We added this because both MySQL and MS SQL Server seemed to not like having connections around for long periods of time and would close them at inopportune times. Maybe SQL Object could do something similar. Regards Dave -- David Warnock, Sundayta Ltd. http://www.sundayta.com iDocSys for Document Management. VisibleResults for Fundraising. Development and Hosting of Web Applications and Sites. |
From: Ian B. <ia...@co...> - 2004-03-18 03:38:52
|
On Mar 17, 2004, at 8:18 PM, David Warnock wrote: > Our Java connection pool tests every connection before it gives it to > the client (by setting autocommit). If the test fails then the > connection is removed from the pool and the next connection (or if > required a new connection) is returned. > > We added this because both MySQL and MS SQL Server seemed to not like > having connections around for long periods of time and would close > them at inopportune times. > > Maybe SQL Object could do something similar. It would be easy to add *if* there's an interface to do this with the database driver. If there was, DBAPIConnection.getConnection() could ping the database before returning the connection. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
From: David W. <da...@su...> - 2004-03-18 09:31:06
|
Ian, > It would be easy to add *if* there's an interface to do this with the > database driver. If there was, DBAPIConnection.getConnection() could > ping the database before returning the connection. Looking at the db api spec and DBAPIConnection I wonder what would happen if we called rollback again in the getConnection. In theory there cannot be a transaction in progress as release connection will have already done a commit or rollback. So what is the effect of calling rollback, rollback on a connection? I guess we might get an exception which is easy to cope with, but will it do enough for us to know if the connection is valid? Otherwise it will need to do it in the db specific classes eg for mysql there is conn.ping() for mysql see http://www.esrf.fr/computing/bliss/python2/MySQL/MySQLdb-2.html Regards Dave -- David Warnock, Sundayta Ltd. http://www.sundayta.com iDocSys for Document Management. VisibleResults for Fundraising. Development and Hosting of Web Applications and Sites. |
From: Ian B. <ia...@co...> - 2004-03-18 16:37:54
|
David Warnock wrote: > Looking at the db api spec and DBAPIConnection I wonder what would > happen if we called rollback again in the getConnection. > > In theory there cannot be a transaction in progress as release > connection will have already done a commit or rollback. > > So what is the effect of calling rollback, rollback on a connection? I > guess we might get an exception which is easy to cope with, but will it > do enough for us to know if the connection is valid? That seems like it might be problematic. For instance, what if rollback is a no-op or something? It shouldn't be, but I wouldn't feel confident that there's not a hidden corner case in the semantics. > Otherwise it will need to do it in the db specific classes eg for mysql > there is conn.ping() for mysql see > http://www.esrf.fr/computing/bliss/python2/MySQL/MySQLdb-2.html That looks like the right thing to use. Doing it in a database-specific way is no problem. It just requires an additional method call in getConnection (say, pingConnection), which by default is a no-op, and we override it for the various databases. Ian |
From: David W. <da...@su...> - 2004-03-18 17:39:59
|
Ian, > That seems like it might be problematic. For instance, what if rollback > is a no-op or something? It shouldn't be, but I wouldn't feel confident > that there's not a hidden corner case in the semantics. Agreed. It is one of those times when the db api spec compared to the jdbc spec is a bit frustrating. >> Otherwise it will need to do it in the db specific classes eg for >> mysql there is conn.ping() for mysql see >> http://www.esrf.fr/computing/bliss/python2/MySQL/MySQLdb-2.html > > That looks like the right thing to use. Doing it in a database-specific > way is no problem. It just requires an additional method call in > getConnection (say, pingConnection), which by default is a no-op, and we > override it for the various databases. I like this. This also allows for another option in the future which is a background thread that slowly loops through the pool testing and refreshing the connections. It is more code but can help responsiveness in situations where you have long periods with little activity and then a burst. With the test only when you ask for a connection you could find that in a burst of activity all connections are failing the tests and so you have not benefited at all from the pool. Regards Dave -- David Warnock, Sundayta Ltd. http://www.sundayta.com iDocSys for Document Management. VisibleResults for Fundraising. Development and Hosting of Web Applications and Sites. |
From: Scott R. <sc...@to...> - 2004-03-18 23:55:00
|
On Thu, 2004-03-18 at 11:34, Ian Bicking wrote: > That looks like the right thing to use. Doing it in a database-specific > way is no problem. It just requires an additional method call in > getConnection (say, pingConnection), which by default is a no-op, and we > override it for the various databases. +1 - yes, please. The DBA who keeps bouncing the SQL server without the app server is my biggest headache, right above the other DBA who keeps changing data from under SO and not refreshing the app server... It would be nice if there was a baked-in mechanism to turn the connection test off if it effects performance during heavy tasks, though. I've never benchmarked MySQL's ping, so this may be a pointless point... Does the java autocommit test affect performance at all? |