[ZCM] [ZC] 1714/ 1 Request "AttributeError: TmpStore instance has no attribute 'loadBefore'"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1714 Update (Request) "AttributeError: TmpStore instance has no attribute 'loadBefore'"
 Status Pending, Database/bug medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/1714

==============================================================
= Request - Entry #1 by Anonymous User on Feb 25, 2005 11:16 pm

Hi all,

I'm doing some development work with ZODB 3.3.  I find that after I commit a transaction on one connection, and then - with another connection - commit a subtransaction and then attempt to access a persistent object that wasn't already loaded, an AttributeError exception is raised.  Here's the traceback:

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/ZODB/Connection.py", line 815, in setstate
    self._setstate(obj)
  File "/usr/lib/python2.4/site-packages/ZODB/Connection.py", line 848, in _setstate
    self._load_before_or_conflict(obj)
  File "/usr/lib/python2.4/site-packages/ZODB/Connection.py", line 875, in _load_before_or_conflict
    if not (self._mvcc and self._setstate_noncurrent(obj)):
  File "/usr/lib/python2.4/site-packages/ZODB/Connection.py", line 887, in _setstate_noncurrent
    t = self._storage.loadBefore(obj._p_oid, self._txn_time)
AttributeError: TmpStore instance has no attribute 'loadBefore'

I went ahead and turned on the logging mechanism of the ZODB, and I found that something similar to the following (the connection ids and the oid change) is spit out before the exception is raised:

Fri, 25 Feb 2005 19:30:51 DEBUG    commit <Connection at b7c2966c>
Fri, 25 Feb 2005 19:30:51 DEBUG    commit
Fri, 25 Feb 2005 19:30:52 DEBUG    new transaction
Fri, 25 Feb 2005 19:30:52 DEBUG    commit <Connection at b7d541ec>
Fri, 25 Feb 2005 19:30:52 ERROR    Couldn't load state for 0x4c6a

All of these connections are made through ZEO.  Here's my ZEO client config file:



<zodb>
    <zeoclient>
        name elegance
        server localhost:10432
        storage elegance
        wait false
    </zeoclient>
</zodb>



... and my ZEO server config file:



# ZEO configuration file

%define INSTANCE /home/devin/src/elegance/test

<zeo>
  address 10432
  read-only false
  invalidation-queue-size 100
  # monitor-address PORT
  # transaction-timeout SECONDS
</zeo>

<filestorage elegance>
  path $INSTANCE/var/Data.fs
</filestorage>

<eventlog>
  level trace
  <logfile>
    path $INSTANCE/log/zeo.log
  </logfile>
</eventlog>

<runner>
  program $INSTANCE/bin/runzeo
  socket-name $INSTANCE/etc/zeo.zdsock
  daemon true
  forever false
  backoff-limit 10
  exit-codes 0, 2
  directory $INSTANCE
  default-to-interactive true
  # user zope
  python /usr/bin/python2.4
  zdrun /usr/lib/python2.4/site-packages/zdaemon/zdrun.py

  # This logfile should match the one in the zeo.conf file.
  # It is used by zdctl's logtail command, zdrun/zdctl doesn't write it.
  logfile $INSTANCE/log/zeo.log
</runner>



Looking through ZODB/Connection.py, I see that the only place where self._storage is set to an instance of TmpStore is in tpc_begin, and that's only if a subtransaction is being committed and self._tmp is None.  In abort_sub, self._storage is set back to self._tmp, but it doesn't look like self._storage is set back to the regular storage if the subtransaction commits without problems (I could be wrong - I'm only going on what I see in ZODB/Connection.py).

I've looked through the other bugs for bugs similar to this one, but haven't found any similar bugs (which I could attribute to my naivety :)).

I apologize in advance if this is an error on my part.  I've been looking for potential problems in my code for a few days now, without success.

Thanks in advance,
Devin

==============================================================