Heikki,
> > It might be that some DB would suffer from the problem you describe
> > (client blocks because the connection is busy) and maybe this is what
> > would happen with Postgres (if it supported tx interleaving) but some
> > other DB might well be able to run everything asynchronously.
>
> You're right that if the DBMS is capable of receiving and processing
> messages incoming asynchronously, there's no problem. However, I think
> such systems are an exception, not a norm.
>
> And no, I don't think it's sensible to expect a DBMS to redesign it's
> client/server protocol just to support this behavior. There's nothing
> that can't be done without it.
I totally agree with you but I think the ones supporting this feature
have a serious advantage over the ones that don't.
On the other hand, you've had good argument indicating that this
advantage might not exist if increasing the connection pool just gives
the same performance.
I'll dig the subject deeper next time I run a benchmark.
> > This has absolutely nothing to do
> > with XA nor interleaved transactions and you could reproduce the exact
> > same behavior with two different connections.
>
> I challenge you to do so. ;)
Done. See attached test case.
> Actually I tend to agree that heuristics as you define them would be
> useful. What I disagree about is that it's a required and essential part
> of the JTA/XA spec. Doing it would be a small patch to both the server
> and driver. I don't think I care enough to write it myself, but feel
> free to submit a patch!
I agree with you: heuristics are not mandated by any of these two
specs but I'd personally would not go on production with a system not
supporting them.
I'll consider writing that patch if time permits.
Ludovic
