> You're completely right on that not all possible problems are solved by
> this, but different solutions are better or worse based also on the odds
> for the problem to actually occur. My code can deal with broken
> transactions, it's just unacceptable if they are broken too often - that
> slows down the system. You must admit that the odds of the
> insert-update-delete to happen at the same time is much lower than just
> 2 inserts happening at the same time, whatever the application usage
> pattern would be. In particular, it's fairly easy to make sure there's
> no delete when updates happen: select the row for update. Only the
^^^^^^^^^^^^^^^^^^^^^^^^^
Of course that's stupid. When you do an update it selects the row for
update... and that will not help in this case.
But the update will not fail. It will just have nothing to update,
which usually is just alright if the row was deleted, meaning that it's
life time ended.
BTW, in my particular problem I can make sure there will be no delete
until all insert/updates are finished.
> insert is the problem cause you don't have the row to lock beforehand.
>
> Cheers,
> Csaba.
>