Heiko,

>> Firebird maintains an internal list of queued requests for locks
>> inside the lock table, but nowhere else.
>
> Is that something I could make use of? That is to say can I have
> several clients requesting a lock on a specific record (waiting for
> success) and the server manages serialization of these?

No, Firebird doesn't lock records - record level concurrency is
handled through versioning, so you can't do that.

>
> If it worked like Oracle's "SELECT ... FOR UPDATE", waiting for the
> lock to succeed, then it would be perfect.

The problem with Oracle's SELECT ... FOR UPDATE is that it breaks
repeatable read - in fact, it allows you to update a record you
can't see - which is pretty much the same as a dirty write.

>
>> You might set up a protocol
>> in your application that uses a mutex (or non-interruptible compare
>> and swap) to synchronize requests for your "table generator".
>
> I am not sure I understand. How can a client mutex synchronize
> requests of different clients on the server?
>

Sorry, I was thinking of a three-layered application. The mechanisms
that come to mind involve shared memory, so they're not applicable.
I think the best solution is to use very short transactions to get
the "sequence" value and expect that most of them will have to rollback
and retry several times.


Regards,


Ann