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
