[ZODB-Dev] Re: [Zope-dev] ZEO, FileStorage, and Undo
Florent Guillaume
fg@nuxeo.com
Wed, 21 Aug 2002 15:45:44 +0200
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