[ZODB-Dev] [fg@nuxeo.com: Re: [Zope-dev] ZEO, FileStorage, and Undo]

[Florent Guillaume]

[oops, that's zodb-dev@zope.org, not python.org]

This question would probably get a better answer from zodb-dev, which I
copy.

brinegar@purdue.edu wrote:
> Hello,
> 
> We have a large FileStorage database ~5 gigs. When any of our users click
> would the "Undo" tab in a management screen the request would eventually
> time out and our ZopeWatch script would restart the server.
> 
> Well this didn't happen every time, it only happens if 20 transactions
> haven't occurred, or haven't occurred recently. In either of these cases
> the entire ZODB is searched for transactions.
> 
> So I wrote a patch for undoLog in FileStorage to batch by days instead of
> # of transactions. This lets us show batches of 2 days at a time instead
> of 20 transactions. Thus we never have to search more than 2 days worth of
> the database. I also MonkeyPatched the manage_UndoForm in App.UndoSupport.
> 
> While doing this I noticed that at the beginning of undoLog FileStorage
> acquires a lock (_lock_acquire). Is this necessary if it's only doing
> reads?
> 
> We have a ZEO with 3 Zeo Clients and 1 Zeo Server when someone hits Undo
> the Zeo Server locks and all 3 clients sit waiting. It
> appears from experience as a user that_lock_acquire locks reads and
> writes.
> 
> We have a system with potential for thousands of content maintainers. It
> is undesirable to have our entire site die for 20 seconds everytime
> one of them clicks "Undo". We could disable Undos, however the
> transactional database was one of the reasons we choose Zope.
> 
> Any suggestions? Is there a way to lock only for writes? So that pages can
> still be served?
> 
> Thank you,
> -Brian Brinegar
>  ECN Web Systems Developer
>  Purdue University
>  West Lafayette, IN

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com