> 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@zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
