Jay writes: > I did this for my writer operations: > > begin immediate; > if busy keep retrying for a reasonable period, if still no lock then error > out. > // lock is now established > // the following should never fail because I have an exclusive lock
But you don't have an exclusive lock yet: "After a BEGIN IMMEDIATE, you are guaranteed that no other thread or process will be able to write to the database or do a BEGIN IMMEDIATE or BEGIN EXCLUSIVE. Other processes can continue to read from the database, however." So a reader process could still BUSY out your updates, if your memory cache fills up and has to spill to disk, but can't due to an extant SHARED lock. At least, according to the documentation and my limited understanding. I like your idea of avoiding the entire retry hassle in the writer process by upping the transaction level to a point where nobody could possibly conflict. Given the large number of retries necessary otherwise, that seems like the best option. Felix
