> 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
>> connector object which ends up in an incorrect state:
>> This is the important part of the traceback.
>> line 460, in IsValidUser
>> result = self.execute('extraaccount.IsValidUser',
>> self.IsValidUser.__doc__, **params)
>> line 125, in execute
>> return queryForResults(connection, query)
>> line 28, in queryForResults
>> line 417, in execute
>> return ZopeCursor.execute(self, operation, parameters)
>> line 261, in execute
>> operation, parameters = self._prepareOperation(operation,
>> line 278, in _prepareOperation
>> encoding = self.connection.getTypeInfo().getEncoding()
>> line 798, in setstate
>> raise ConnectionStateError(msg)
>> ConnectionStateError: Shouldn't load state for 0x1d54 when the
>> 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.
First thanks for the response.
>> 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?
The object class is known to me. It is a the postgres database adapter.
I found this issue, which may cause the problem...
I used to use a database adapter configured as a local utility. However, I
changed to configuring it as a global utility because I need to access the
database in some event subscribers and the event subscribers. I deleted
the database adapter from my ++etc++site, but when I looked at the
@@registrations.html view it was still there. I have removed the adapter
using the @@registrations.html view and restarted.
Unfortunately the problem takes some time to recur and I cannot replicate
it in my test server, so I cannot be sure that this is a resolution.
>> 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)
>> provideUtility(gAdapter, IZopeDatabaseAdapter, name)
> This looks okay-ish to me (latin-1, yuck, is this the 20th century
I am in a parallel run. I can migrate to utf-8 only after I switch off the
old system but I will - I need those euro symbols.
>> 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?
That is just what I needed.
Although I had removed a registration for the deleted object, your snippet
showed me that the object was still in my ZODB. I eventually tracked down
the object as a 'subscriber' to utilities in a local registry....
I deleted the object using...
lsm = root['mysite'].getSiteManager()
from zope.rdb.interfaces import IZopeDatabaseAdapter
# Display the adapter (direct and indirect)
print lsm.utilities.subscriptions((), IZopeDatabaseAdapter)
transaction.begin() # this may not be necessary
# Delete the adapter
# Verify that it is deleted
And now it is finally gone from ZODB.
> Marius Gedminas
> I doubt, therefore I might be.
> Zope3-users mailing list
Zope3-users mailing list