Our OLTP application commonly encounters lock conflicts when (in particular) inserting rows related
to other rows currently being updated. We use pessimistic locking under certain circumstances, but
sometimes it's not directly related to a user having taken control of a record for a few minutes.

It would be relevant (and possibly helpful) for our users to be able to find out who has the lock
getting in their way. It seems silly, really, but it'd be nice. It's all about social stuff --
knowing if the users getting the error just isn't noticing another window they have open, or if
it's someone down the hall gone to lunch, or someone just finishing up and not meaning to be in the
way ...

I know I could kill the FK constraints to get around some of this, but that's a hack I'm not
willing to use. (FB would no longer prevent locks on dependent tables, as there would be none, but
for the rare occasions when a record might be deleted, we no longer have that safety of knowing the
FK's are being taken care of.)

Is there / will there be some way to determine the transaction number that has the lock? And
possibly use that to find out who it is? As I recall, FB 1.5 has a facility to allow a transaction
to find out its own transaction number, which I could use client-side. (You likely don't want to
know that the app logs in as a single user, restricting permissions client-side, thus not allowing
us to just look at the user logged in, owning the transaction, at least not directly.)

-Philip