[ZODB-Dev] Mysterious traceback
Jim Fulton
jim@digicool.com
Thu, 01 Mar 2001 10:27:52 -0500
Andrew Kuchling wrote:
>
> We're seeing some mysterious tracebacks being raised from the ZODB
> machinery used underneath Quixote, and can't figure out why.
>
> Here's the traceback.
>
> [Tue Feb 27 10:38:52 2001] vfab.fcgi starting up
> Traceback (most recent call last):
> File "/www/cgi-bin/vfab.fcgi", line 33, in ?
> main()
> File "/www/cgi-bin/vfab.fcgi", line 26, in main
> publish.call_fcgi()
> File "/www/mxpython/quixote/publish.py", line 326, in call_fcgi
> call(f.inp, f.out, f.err)
> File "/www/mxpython/quixote/publish.py", line 307, in call
> sess_coll.commit()
> File "/www/mxpython/mems/lib/persist_session.py", line 41, in commit
> get_transaction().commit()
> File "/www/python/lib/python2.0/site-packages/ZODB/Transaction.py", line 250,
> in commit
> j.tpc_begin(self)
> File "/www/python/lib/python2.0/site-packages/ZODB/Connection.py", line 524,
> in tpc_begin
> self._storage.tpc_begin(transaction)
> AttributeError: 'None' object has no attribute 'tpc_begin'
>
> The above exception is raised at transaction commit, as you can see.
> Occasionally the exception is raised while accessing an object, with
> AttributeError: 'None' object has no attribute 'load' -- same root
> problem, _storage being None.
Hm. That's curious. I've seen this some too.
> Looking at Connection.py, self._storage is reassigned as part of the
> transaction committing machinery; this code is hard to understand, and
> we haven't dissected it sufficiently yet.
This is done when the connection is opened and closed, and when
dealling with sub-transactions. Are you using sub-transactions
for anything?
> We can't see a pattern;
> different pages trigger the error, and they don't always trigger it.
> We don't use threads (though perhaps asyncore or some ZODB components
> does under the covers), but this might be a race condition of some
> sort.
I don't think this is a rece condition either. Zope only lets
one thread use a connection at a time and we've been seeing this
too lately.
> We'll keep digging, but it's difficult work. Perhaps someone here has
> seen this failure mode before,
Yes, very intermittetly.
> and can suggest a cause?
Not yet. I'll take another look. Any clues you can provide
would be helpful.
Jim
--
Jim Fulton mailto:jim@digicool.com Python Powered!
Technical Director (888) 344-4332 http://www.python.org
Digital Creations http://www.digicool.com http://www.zope.org