[ZODB-Dev] Mysterious traceback

[Andrew Kuchling]

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.

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

We'll keep digging, but it's difficult work.  Perhaps someone here has
seen this failure mode before, and can suggest a cause?

--amk