??>> theoretically we could get a deadlock, but it only happens if ??>> application updates object in different order, and this can be ??>> avoided.
LPP> Note that concurrent writes to an indexed slot will currently have LPP> a pretty high chance of inducing a deadlock. Try the new test suite. LPP> In general it seems to be a tough bet relying on this. aha, so you mean we need retries anyway? i did not look into tests source code and thought that you're provoking them in "traditional" way. 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. 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. if you have an idea how our code can trigger situation as described in pgsql manual please drop a note. ??>> also, we have a race condition in update-or-insert implementation, but ??>> this could be avoided either via savepoints, LPP> But SPs are just a way to have more fine-grained retries, so it's LPP> not really different from retrying the whole txn... no, for our purposes savepoints just alter error handling policy of pgsql. such retries can be implemented in a stored procedure code, totally transparent from lisp side, or in db-postmodern code, totally transparent from application. 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. ??>> or via locking. LPP> pgsql automatically locks, doesn't it? implicitly it obtains only "minimal" locks. knowing semantics of operations, we can explicitly deman stricter locking, and this way avoid deadlocks or race conditions. 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. 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 _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
