The row lock is held by the RDBMS itself on behalf of the client. When the client goes away, times out (configuration) etc. -- the transaction aborts -- then the RDBMS releases it. You don't get exactly once here, because between performing some action on the work item and marking the item as finished and committing you can still crash. This is an at least once solution in the general case.
sorry!! I'm not sure I understand your response? when you say 'You don't get exactly once here' what is does 'here' refer to?
Upon reflection, true exactly-once semantics requires multi-phase commit, transitively through the system - this sort of tight coupling is tricky in practice.
Hence my question/proposal, which is practical/poor-man's solution using timeouts.
