Subject | Re: [Firebird-Architect] Vulcan architecture and lock tables |
---|---|
Author | = m. Th = |
Post date | 2006-12-18T09:13:39Z |
Adriano dos Santos Fernandes wrote:
complex code IMHO is very hard to find which TID is the offending one,
even the communication layer with Fb 'knows' it. And, also, perhaps,
some libraries don't even expose it. For you, as *server developer*
(AFAIK) is straightforward, I suppose, to put this there.
implementation (congratulations, really...) the feature coverage and
expandability is reduced in, let's say, a 'sensible' manner, IMHO.
Thanks a lot anyway,
m. th.
> = m. Th = wrote:How? Remember, I speak from the *application developer* POV. In a
>
>> 1. Transaction %d is the transaction which holds the resource or "our"
>> transaction? IMHO, is better to write both numbers in the message...
>>
>>
> The one that holds the lock. Our transaction number is already
> accessible, no need to report it.
>
complex code IMHO is very hard to find which TID is the offending one,
even the communication layer with Fb 'knows' it. And, also, perhaps,
some libraries don't even expose it. For you, as *server developer*
(AFAIK) is straightforward, I suppose, to put this there.
>> 2. What if you have more than two transactions in a deadlock IOWOh... hence, while the feature has a very low cost and I salute its
>> "deadly-embrace"?
>>
>>
> My proposal is to address update_conflict, and not deadlock in general.
>
>
implementation (congratulations, really...) the feature coverage and
expandability is reduced in, let's say, a 'sensible' manner, IMHO.
Thanks a lot anyway,
m. th.