--- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@a...> wrote:

>
> > it used to be, did you remove that code? (not arguing, just asking)
>
> We had casual NPEs in JBoss under heavy load. And the most nasty

thing was

> that when the error happened, JayBird was not able to recover from

it, only

> restart of JBoss helped. It was not reproducable, but was related to

heavy

> load and possibly race conditions. I have tried to fix it between

1.0.1 and

> 1.5.5, but failed.
>
> In 2.0 I tried to move every map that could cause such problems to the
> FBManagedConnection and taking care of synchronization local to that
> instance. I think we have discussed this change, but maybe it was

not clear

> that the indirection layer will disappear. Hopefully the new version is
> immune to these problems (so far no reports were posted).
>
> > This may be the best solution. However IIRC it has the disadvantage
> > that the branches will not be able to see each others work.
>
> Yup, IIRC, so called losely coupled resources.
>
> > I think that is why I originally coded the extra layer of

indirection. I

> > don't know of any situations in which an actual app server would

need to

> > call join: does anyone else?
>
> Neither do I, but maybe there are some cases...
>
> > If there are no good use cases I think not having the extra

indirection

> > layer and fixing isSameRM as you suggest
> > is good.
>
> Well, JTA suggests to join when it is same resource manager,

otherwise it

> should start new branch. So even if application servers would like

to join,

> this should effectively prevent them doing so, the main outcome

would be

> just more physical connections than in old scenario, in fact as many as
> application asked for. So the only possible problem is when application
> relies on tightly coupled resources, but runs against loosely

coupled one.

> Do I miss something here?
>
> Roman
>

Lowering the number of transactions can definitely improves processing
speed a lot, especially in case of high server load.
Remember that a 2 resouces 2PC typically requires at least 5 disk
forces (including DB and TM: 2 per resource + 1 for TM) while a simple
1PC requires only one. The potential benefit could be high but maybe
Firebird's MGA lowers that gain, I don't know.

Anyway, correctness is more important than speed. Limiting isSameRM is
I think a good candidate fix to be implemented before the final
Jaybird2 release.

On the other hand, having this optimization is nice to have, just like
it would also be nice to see support for XA_RDONLY. Both can be
considered very low priority and only implemented if the DB engine
provides necessary help.


Thanks a lot to both of you Romand and David for answering my
question. You already did a great job by providing us the only open
source DB truly supporting JDBC XA.

Ludovic