Re: upgrading to ZODB5

Jim Fulton <[email protected]>
Newsgroups gmane.comp.web.zope.zodb
Message-ID <CAPDm-FhZ5r=S67jKr5JyNQWhTrE6qkzmSaR+oYENJx=eAHcs9A@mail.gmail.com>
On Fri, Mar 31, 2017 at 2:04 PM, Héctor Velarde <[email protected]>
wrote:

> I was checking the changelog of the newest version of ZODB and found this
> specially interesting:
>
> - Drop support for old commit protocol. All of the build-in storages
> implement the new protocol. This new protocol allows storages to
> provide better write performance by allowing multiple commits to
> execute in parallel.
>
> I saw Jim is already running tests against Plone 5.1 and I was wondering:
>
> is something needed (beyond upgrading the eggs) before we can start using
> this on existent deployments?
>

If by "this" you mean "allowing multiple commits to execute in parallel",
first some clarification.

ZEO already executes the first phase of two-phase commit in parallel.  ZEO
only executes the second phase of two phase commit for one client at a time.

NEO allows most of the processing for the second phase of two-phase commit
to happen in parallel and even on separate machines.  There's still a
global commit lock but it's held for a much shorter time.  I would love to
see shootout (or similar) results for NEO.

ZEO byteserver also allows most of the second-phase processing to happen in
parallel, but it is unfinished.

I'm not sure of the situation with RelStorage, but I think it's similar to
ZEO.

These changes were made for 2 reasons:

   - Better support NEO, so they could drop some of their monkey patches.


   - Potentially make ZEO faster by doing more of the second phase in
   parallel.  This didn't work out because the computational overhead
   outweighed the benefit, especially because of the GIL. (The byteserver is
   much faster than ZEO, but IDK if the ability to do more of the second phase
   in parallel was a factor. But it isn't subject to the GIL.)
   - Cleanliness. The changes made the protocol cleaner. :)

The main potential benefit for ZEO is avoiding holding the commit lock
while waiting for the client to respond to the vote response with a finish
call. It has occurred to me recently that we could get the same benefit by
allowing a vote option to immediately finish.  This could be used if the
ZEO client was the only data manager involved in the client transaction,
which I assume is the common case.


> what about zc.zrs? do we use latest version?
>

Sorry, recently I learned that ZRS doesn't work with the latest ZODB.
whimper.

I think only modest changes are needed, except it will take a lot of work
to get the tests passing. :(  I started on it and got pulled off on other
projects. I'll try to get this done soon.

Jim

-- 
Jim Fulton
http://jimfulton.info

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.