At 06:28 PM 10/5/2005, Howard Chu wrote:
I believe the only reason a write in back-bdb/hdb would complete out of order is because the transaction was randomly selected to resolve a deadlock, so it had to abort and retry, and some newer op managed to complete in the intervening time. I think there are two possible solutions here:
1) get a new CSN whenever a write op needs to abort and retry.
2) change the deadlock detector strategy to always select the youngest transaction to abort.
I'm not sure that (2) is sufficient by itself, but (1) ought to be
I believe neither of these are sufficient. One cannot
predict which of multiple modifications commits first
(with or without retries). Which is why the lowest
outstanding CSN is to be used for the cookie...