|Subject||Re: [Firebird-Java] Re: problem with XAResource.TMJOIN|
> 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 disadvantageYup, IIRC, so called losely coupled resources.
> that the branches will not be able to see each others work.
> I think that is why I originally coded the extra layer of indirection. INeither do I, but maybe there are some cases...
> don't know of any situations in which an actual app server would need to
> call join: does anyone else?
> If there are no good use cases I think not having the extra indirectionWell, JTA suggests to join when it is same resource manager, otherwise it
> layer and fixing isSameRM as you suggest
> is good.
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?