I wrote:

>> Sounds like getting those 15 counter values may happen within the same
>> transaction. No other transaction will be allowed to update that
>> record until the transaction that did the update commits. Neither will
>> those other transactions be allowed to update the record until they
>> can see the most recent version (depending on transaction isolation).

Heiko wrote (two different mails):

> Yes, it sounds a bit like that. But I am sure that every call for the
> next counter value starts (and ends) a new transaction.
>
> And I already have some implementation. But it seems to have problems.
> Like getting deadlocks too often. Though I retry several (30) times to
> get access to the counter.

OK, if each retry happens in a different transaction, then I don't
understand and you can ignore the rest of this answer.

If you meant that you're certain that every update commits, whereas the
30 retries happens within the same transaction and you use snapshot
isolation, then the explanation could be pretty logical:

The update conflict is due to the record having been modified (by
another transaction) between transaction start and the update
committing. Since the visible version of the record doesn't change for
this transaction, no retries will ever succeed and you're just
postponing the time until the update conflict is reported to the user.

Set