[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