> >
> > >Is this a firebird bug, or an IBObject bug?
> >
> > It's neither. It just needs a bit more understanding on your part
> of how
> > transactions work. With a NO WAIT transaction, an update request will
> > return a lock conflict immediately if conflict conditions exist.
>
> There should not be a conflict:
> consider the following psuedo code:
>
> enter critical section
> insert()
> ...
> post()
> commit()
> leave critical section
>

do you start the trans in this section?
what is the setting in the transaction with regard to close/refresh? if
refresh, then you are starting a new trans in the section, it should be
close.
without knowing more about your threading logic it's hard to say. Something
about it doesn't smell right with regard to getting any benefit out of
multiple threads which appear to be blocking each other. There must be some
pretty lengthy client side manipulations going on to make all this worth it.
If you serialise so much, then it would appear that a non-threaded approach
would be just as fast.
But to me the bottom line is: FB's transaction basics are very mature. I've
been trusting them with all manner of both threaded and non-threaded logic
for nearly ten years. I have never struck a bug with it. As for IBO, the
transaction logic/API connection is also very basic to the whole model and
is also very mature (no change for a very long time either). I would not
suspect it as the reason for your trouble either.
I would still say your code is the first port of call to discovering the
behaviour you are not happy with. You may need to change a few things quite
radically to test some hypotheses.
Alan