On Wed, Jan 07, 2009 at 01:28:24PM -0000, kevin gill wrote: > I am having a problem on my live site. The problem is todo with a DataBase > connector object which ends up in an incorrect state: > > This is the important part of the traceback. > > File > "/home/kevin/src/castingzone.tables/castingzone/tables/person/extraaccount_db.py", > line 460, in IsValidUser > result = self.execute('extraaccount.IsValidUser', > self.IsValidUser.__doc__, **params) > File "/home/kevin/src/castingzone.utility/castingzone/utility/db/db.py", > line 125, in execute > return queryForResults(connection, query) > File "/home/kevin/src/castingzone.utility/castingzone/utility/db/db.py", > line 28, in queryForResults > cursor.execute(query) > File > "/srv/zope/hosting/castingzone/instance/hacks/psycopgda-1.0-py2.4.egg/psycopgda/adapter.py", > line 417, in execute > return ZopeCursor.execute(self, operation, parameters) > File > "/srv/zope/hosting/castingzone/eggs/zope.rdb-3.4.0-py2.4.egg/zope/rdb/__init__.py", > line 261, in execute > operation, parameters = self._prepareOperation(operation, parameters) > File > "/srv/zope/hosting/castingzone/eggs/zope.rdb-3.4.0-py2.4.egg/zope/rdb/__init__.py", > line 278, in _prepareOperation > encoding = self.connection.getTypeInfo().getEncoding() > File > "/srv/zope/hosting/castingzone/eggs/ZODB3-3.9.0_dev_r77011-py2.4-linux-i686.egg/ZODB/Connection.py", > line 798, in setstate > raise ConnectionStateError(msg) > ConnectionStateError: Shouldn't load state for 0x1d54 when the connection > is closed
If I'm not mistaken, this error typically occurs when you try to hold a reference to a Persistent object across transaction boundaries (e.g. by storing it in a global). Don't do that. Sometimes this happens in unexpected places (e.g. having a schema with an Object field that has a default value, and an edit form -- the default value is never explicitly copied, so you may end up with multiple references to it). I'm not saying this could be your problem; I'm just trying to remind you that some globals may be difficult to notice if you haven't been burned by them before. > Once the server gets into this state, it seems to repeat often. > > The object in question is a database connection object. Are you talking about the persistent object with oid 0x1d54? > I have just > retrieved it via an adapter lookup. It is not stored. > > connection= zope.component.getUtility(IZopeDatabaseAdapter, > CONNECTION_NAME, self.context)() > > The database connection is provided by a global utility. The important > code is as follows: > > def connection_directive(_context, name=CONNECTION_NAME, > connection_string='', encoding='latin-1'): > """Process a db:Connection zcml directive""" > > # Don't delay to the end of the configuration process - > gAdapter = PsycopgAdapter(connection_string) > gAdapter.setEncoding(encoding) > gAdapter.connect() > provideUtility(gAdapter, IZopeDatabaseAdapter, name) This looks okay-ish to me (latin-1, yuck, is this the 20th century still?). > Any help in narrowing down this problem would be greatly appreciated. It > is making my live system unworkable. Start a debug console (zopectl debug or bin/debugzope), then take a look at oid 0x1d54: >>> from ZODB.utils import p64 >>> app.root()._p_jar.get(p64(0x1d54)) The interesting bit of information is the class name of that object. Then look through the sources trying to determine the lifetime of that object: where are references to it created? Marius Gedminas -- I doubt, therefore I might be.
Description: Digital signature
_______________________________________________ Zope3-users mailing list Zope3email@example.com http://mail.zope.org/mailman/listinfo/zope3-users