[ZODB-Dev] ZEO 2.0a1 release

[Jeremy Hylton]

>>>>> "TD" == Toby Dickenson <tdickenson@geminidataloggers.com> writes:

  TD> Eeek - this came around quickly.

You mean you're surprised that we have a 2.0 alpha already?  I'll bet
most of the code has been hanging around for more than a year.

  >> If you're interested in contributing, now is a great time to
  >> propose changes.

  TD> Since you asked, I have a couple of ideas that have come out of
  TD> my DirectoryStorage work that I havent shared yet;

  TD> 1. It would be nice for a server-side storage to be able to
  TD>    declare that he
  TD> has some extra methods that should be proxied from the
  TD> ClientStorage. That could happen in ZEO1, but only by
  TD> subclassing everything.

Good idea.

  TD> 2. I am suprised that you have a DelayedCommitStrategy thing
  TD>    inside ZEO,
  TD> rather than extending the storage interface to allow concurrent
  TD> commits.  (that would be a more obvious way to do it, but maybe
  TD> not better). Thinking aloud, maybe the storage object could be
  TD> allowed to provide his own DelayedCommitStrategy object?

I had considered this but found two difficulties with it:

1. It means changing the storage API and updating other storages to
   take advantage of it.  I don't want ZEO2 to require changes to the
   storage API, and I want to get the advantages of sending data for
   multiple transactions regardless of whether the underlying storage
   supports the feature.

2. I looked at changing FileStorage to provide better support for
   multiple concurrent commits, but it looked hard.  It seems like the
   current scheme has too many tempfiles:  The ZEO server writes
   everything to a tempfile.  Then the FileStorage writes everything
   to a tempfile, and copies the data when it commits.  It would be
   nice if we only needed to copy the data once.

   But FileStorage's tempfile format is deeply connected with the
   FileStorage log format.  It needs to include serialnos for each of
   the data records, and the serialno depends on the transaction
   timestamp.  So there's no easy way to figure out the serialno for a
   transaction that is delayed.

   So the FileStorage was mostly going to do what the StorageServer
   now does.  Write the basic data in a log, then run it through the
   regular commit machinery when its turn comes.  Since this was the
   case, it seemed cleaner to put the code in StorageServer and get
   the benefits for all storages.

I think it's fair to revisit the issue for ZODB 4 / Zope 3, but I
don't know when I'll have time for that.

Jeremy