On Thu, Sep 03, 2009 at 01:33:53PM +0200, Sophana K wrote: > > > It looks like its related with the mysql server being overloaded. But > > > > I think you mean "restarted", not "overloaded", right? > > > > No, the mysql server is very loaded.
Then how it's related to SQLObject? Timeouts between clients and the server? > > > I still don't understand why. > > > I've been looking at the source and don't understand how this can > > > happen. I never call rollback in my source, and always make > > > transactions through doInTransaction. > > > > doInTransaction() calls rollback() on any exception. > > > > I understand this. > rollBack is called on a Transaction object by doInTransaction. > But it just throws away the object just after, doesn't it? > This is why I don't understand how it can happen if I don't explicitely call > rollback myself. > Could it happen during the contruction of the Transaction object itself? > As you might see in the traceback, the error happens while the Transaction > is created. The only place I could suspect is the call dbConnection.getConnection() in Transaction.__init__(). > I forgot to say. It looks that once this happened once, all upcoming > transactions fail the same way. > > In the Transaction constructor: > class Transaction(object): > def __init__(self, dbConnection): > # this is to skip __del__ in case of an exception in this __init__ > self._obsolete = True > self._dbConnection = dbConnection > self._connection = dbConnection.getConnection() > self._dbConnection._setAutoCommit(self._connection, 0) > self.cache = CacheSet(cache=dbConnection.doCache) > self._deletedCache = {} > self._obsolete = False > > _obsolete is set to True. > Then you have self._connection accessed. > So the __getattr__ method should be called, doesn't it? > __getattr__ first calls self.assertActive() which checks that _obsolete is > False. No, self._connection is assigned: self._connection = dbConnection.getConnection(). After this __getattr__ is never called on accessing the self._connection. __getattr__ is called on accessing non-existing attributes. In the Transaction class it is used to delegate attribute access to the underlying connection. > > What connection have you assigned to hubNoCache? It seems it's a (rolled > > back) transaction, not a simple connection. > > > > > hubNoCache=ConnectionHub() > hubNoCache.processConnection = connectionForURI(database+'&cache=') Looks good, nothing strange here. Could it be an old transaction is stuck in hubNoCache? > > > In the traceback I don't understand why there are missing step between > > > conn = old_conn.transaction() and self.assertActive(). It should go > > > through the Transaction constructor. I recommend you to investigate it deeper: add a lot of debugging output to the dbconnection.py to find out what is the connection, what is the transaction and what is the attribute that cause the problem. Oleg. -- Oleg Broytmann http://phd.pp.ru/ p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss