Mike Spille has released an appendix to his last installment on XA transactions. This piece contains the source code wrapped up as an "alpha release" for us to follow along to the discussion. He continues to give us a high level look at the code, and the drivers contained.

Read XA Exposed III.I, and XA Exposed, Part III: The Implementor's Notebook

Hi Mike,
Nice write up. I briefly looked over the part I and part II but didn’t see you discussing parallel (asynchronous) prepare and commit/rollback implementations for optimizing on multiple XA resources. Is that omitted on purpose or otherwise?

Thanks in advance,
Nikita.
xTier - Service Oriented Middleware

I may have touched on it briefly in Part II - I'd have to go back and check. There _was_ extensive discussions about it on the TSS thread for XA Exposed Part I. I'm still surprised that parallel prepare & commit isn't common in application server implementations - everyone seems to do it serially, which is slow enough but slows down increasingly for each resource you add. Only BEA has claimed to have an async implementation.

   -Mike

Hi Mike,
Yeah, I remembered I saw it somewhere... Thank for pointing. I am too not sure what would hold someone from implementing parallel prepare/commit/rollback let alone transaction logging. Judging by our experience (we have both transaction log and parallel implementations) it was fairly inexpensive to do it. In my opinion parallel prepare/commit/rollback should be a default implementation strategy while transaction log is simply dictated by data integrity requirement. Go figure...

Regards,
Nikita.
xTier - Service Oriented Middleware

>
>    -Mike

I'm pretty sure I mentioned at the time that the Bluestone Transaction Service/Hewlett-Packard Transaction service (and now Arjuna Transaction service) does this too. Async prepare and commit.

Mark.

Oops, sorry Mark, that's right. As someone who's done TM/App Server stuff, do you have any idea why this isn't more wide spread?

     -Mike

Mike, the two main reasons for systems implemented post mid-1990's that I've come across are:

(i) the customer deployments don't use many (more than 2) resources and those resources always respond quickly, so they see this optimization as not being necessary.

and

(ii) they've never thought about it (strange as it may sound!)

In the "good old days" of C, C++, COBOL and assembler implementations before the mid-1990's doing multi-threaded programming was extremely difficult. Work on pthreads was pretty active around that time, and multi-thread capable operating systems were becoming a reality (Sun's lwp thread package, for example, was amongst the most stable at that time), but just prior to that you either had to roll your own, or use multiple processes to get parallelism. Some TP systems developed between the 60's and 90's did have their own multi-threading support built-in, but it tended to be used selectively. Other TP systems were (and still are) single threaded, and optimized for that.

Now that I've shown my age, I'll return you to your regular scheduled program ;)

Mark.

Oops, sorry Mark, that's right. As someone who's done TM/App Server stuff, do you have any idea why this isn't more wide spread?

     -Mike

Isn't that three reasons ;-?

Isn't that three reasons ;-?

How do I mark you as noisy ;)

Hello,
I need to writer a xa driver for my application.

In my application, i got a multithread tcp server, that it does somethings and returns some results (it dont minds).

Ok, i need that -the server- can participate in a xa transaction. how can i write an xa driver?

And, for example, anyone has needed a xa transaction manager for file io operations? I've needed it a lot of times !

Can i use an existing framework to do this task?

Can i get something like "xapool library" to xa generic task agains jdbc task? can you help me, please?

Thank you jsanza@terra.es

Do you have the latencies for these thruput readings?

I've got preliminary latency numbers, but nothing formal yet.

For the most part, latency is a function almost entirely of the disk forcing time, with a bit of overhead for locking a couple of monitors and writing data out to an NIO buffer. On my rather sad disk at home, the numbers look something like this:

   1 thread - ~31 TPS
   5 threads - ~31 TPS per thread
   50 threads - ~28 TPS per thread
   200 threads - ~22 TPS per thread

Invert with 1 second and you get:

   1 thread - ~32 millis/tran
   5 threads - ~31 millis/tran
   50 threads - ~35 millis/tran
   200 threads - ~45 millis/tran

Actual disk force times are around the 30 millisecond mark (I don't have exact figures right now). I'm working on stats with faster disks, and hunting around for a multi CPU machine as well.

     -Mike

Mike, a top-level directory in that tar file would be better. I am glad I always check first ...

Arg, thanks for pointing that out. I knew I should've done a more formal packaging procedure. I'll fix it tonight, and I'm glad you checked and didn't whack a directory with a bunch of stuff.

    -Mike