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
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
