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