[Zope3-Users] Need help with an urgent problem

[kevin gill]

> 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.
>

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)
>>     gAdapter.setEncoding(encoding)
>>     gAdapter.connect()
>>     provideUtility(gAdapter, IZopeDatabaseAdapter, name)
>
> This looks okay-ish to me (latin-1, yuck, is this the 20th century
> still?).
>

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._subscribers[0][IZopeDatabaseAdapter]
print lsm.utilities.subscriptions((), IZopeDatabaseAdapter)

import transaction
transaction.begin() # this may not be necessary

# Delete the adapter
lsm.utilities.unsubscribe((), IZopeDatabaseAdapter)

transaction.get().commit()

# Verify that it is deleted
lsm.utilities._subscribers[0][IZopeDatabaseAdapter]


And now it is finally gone from ZODB.

> Marius Gedminas
> --
> I doubt, therefore I might be.
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>