Using an RDBMS is no cure-all for deadlocks - I can just as easily deadlock with an RDBMS as with my own threads and locks, probably easier.
I try to pick up crumbs of knowledge from my co-workers, and one of the smarter ones gave me this rubric for testing for deadlocks. You need 3 things to create deadlock: 1. multiple locks 2. multiple threads of execution 3. mixed access order to the locks (process 1 has lock A and wants lock B, while concurrently process 2 has lock B and wants A) So to avoid deadlock, invert the rubric and get rid of any one of these elements. One proposed solution was to use a single global lock - this would cancel out criteria number 1. An alternative might be to get rid of multiple threads. Your current design uses a background thread, but if this could be merged in some round-robin fashion with the other needed processing (a generator pool perhaps?), then you could try door #2. If you don't like either of these options, then look at ways to ensure locks are always acquired in the same order - perhaps alphabetically by resource name, or top-down if organized hierarchically - to ensure that locks are never acquired in mixed order. In the case of processes 1 and 2, if all locks were to be acquired alphabetically, then process 2, holding B and wanting A, would have to first release B, then request A and then re-request B. This would break the deadlock with process 1. I don't know if I've really offered anything new, but at least you have some structure with which to approach your question. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
