On Mon, Feb 28, 2011 at 22:12, Shane Hathaway <sh...@hathawaymix.org> wrote: >> And unless I am missing something, we don't >> need to worry about the transactions table either. The rest of >> RelStorage ignores transactions where the packed flag has been set to >> TRUE, so deleting the packed and empty transactions from the table >> will never lead to deadlocks, right? > > It might lead to deadlocks, actually. Deadlocks occur when concurrent > clients try to acquire locks in different orders. SQL databases handle > deadlocks of that type by returning an error to all but one of the > deadlocking clients, similar to the way ZODB deals with conflict errors. > > Also, in SQL, even reading a table usually acquires a lock, so it's > really hard to prevent deadlocks without something like a commit lock. > >> Or am I missing something about >> how RelStorage implements polling and caching? In any case, the >> history-free version doesn't need to lock at all, because it only ever >> touches the pack-specific tables in the pack cleanup. > > True. > >> If the >> transaction table needs no lock protection either, we can get rid of >> the lock during cleanup altogether. I'd like to hear confirmation on >> this though. > > I wouldn't do that. Too risky. (Many database architects say that > deadlocks are normal and should be handled in application code, but in > my experience, deadlocks kill applications under load and I prefer to > put in the effort to avoid them entirely if possible.)
Okidoki, I'll happily defer to you on that. With our database now much much smaller I fear that commit lock during pack clean-up less and less. >> On a side note: I see that the history-preserving object_ref and >> object_refs_added deletion SQL statements have been optimized for >> MySQL, but not for the history-free version. Wouldn't those statements >> not also benefit from using a JOIN? > > Perhaps, but I prefer not to optimize until I see what happens in > practice. Mis-optimized MySQL statements frequently turn out to have > something like O(n^3) performance. I don't really care about that edge-case, I just noticed that the MySQL statements were optimized in one version but not the other. I'll leave tinkering with that to people that actually run RelStorage on MySQL in the first place, I'll focus on the Oracle side. I've added a switch to disable updating the schema during RelStorage start-up, btw. The auto-update of the PL/SQL package bit me at some point, disabling our cluster. Luckily a swift restart of one of the clients reinstated the 1.4 version quickly. :-) We are not quite ready for a full 1.5.0 upgrade just yet.. ;-) -- Martijn Pieters _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
