[ZODB-Dev] [ZODB4] - Shouldn't the new object be added to Connection._created ?

[Jeremy Hylton]

>>>>> "JF" == Jim Fulton <jim@zope.com> writes:

  JF> Ury Marshak wrote:
  >> Scenario: a new object is inserted in existing persistent
  >> container, container gets pickled, persistent_id() is called, the
  >> new object gets assigned oid. Transaction fails. The new object
  >> still has oid and the works.
  >>
  >> We retry the transaction (or even access any attribute on the
  >> object).  The persistent machinery sees the object with
  >> _p_state==3, ghost, tries to unghostify it using a [non-existent]
  >> oid -- BOOM..

  JF> What works? It can't be referenced from the container any more,
  JF> because the container was ghostified. The new object isn't in
  JF> the cache, so I don't see hos the data could be getting
  JF> unghostified, or how it could be ghostified in the first
  JF> place. How is the transaction failing?

A traceback would provide more details than BOOM <wink>.

However, a new object will get added to the cache by commit_store().
If the transaction is later aborted, I don't believe the object is
removed.  Still, I don't see how it could be getting ghostified.

At the moment, I can't recall if/how the state gets set during object
creation.  It's created in the uptodate state, and I assume it doesn't
change until after it has a jar.

  >>> Note that, if the transaction is aborted, the reference to the
  >>> new object will go away and it will disappear, so it doesn't
  >>> really need to be invalidated. You don't need to keep track of
  >>> created objects until they have been assigned oids.
  >>>
  >> The point is that under ZEO the whole thing seems to take
  >> slightly different paths (tpc_abort etc) than when using for
  >> example FileStorage directly.

  JF> That is hard to believe.

The order in which objects are processed depends on lots of random
factors -- likethe order in which things get pulled out of af a dict.
I can believe two different storages can do things in different orders
(eg returning serialnos from a store) and that this affects error
cases.

  JF> When you get a conflict error, do you call
  JF> get_transaction().abort()?

Shouldn't matter.  The TM calls abort() on all the jars when things go
wrong.

Jeremy