> aha, so you mean we need retries anyway? We might. I'm not sure because I'm still not fully into the stuff you are doing.
> if simple slot writes provoke deadlocks that is not OK IMHO. PostgreSQL > documentation > (http://www.postgresql.org/docs/8.1/static/explicit-locking.html#LOCKING-DEADLOCKS) > mentions several resasons why deadlocking can happen, and it doesn't look > like we are triggering one of them explicitly. > so chances are this can be fixed via some modifications of the code. That's all good, but I have a real problem with the stance of saying “let there be good code and we'll have no deadlocks” because the problem whether code is good is undecidable. So I'm for a solution that is as elegant and efficient as possible but will also handle deadlocks if they occur. > as far as i know deadlocks are much worse than conflicts performance-wise -- > because they are detected by the timer, something like once a second, unlike > conflicts that are detected immidiately -- and we should try making them > impossible in working course of operations. That's right. The txn dependency graph will have to be check for cycles regularly. > retries due to conflicts are totally different -- whole txn retry must be > triggered according to txn semantics, it cannot be done transparently, and > application can be impacted if it's code is not side-effect-less. Shouldn't the application programmer always anticipate a transaction abort? > e.g. braindead solution -- before writing, lock whole table so nobody can > write concurrently (but still can read) -- this way we can be sure that > there will be no race conditions, but this will also have considerable > performance impact. Yeah, that's the MySQL solution. I'm against it :) > probably there is some better way to do this.. maybe SELECT FOR UPDATE will > do.. but first i need to investigate what really happens there Thanks, I'll leave this to you for the time being... Leslie _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
