If you have been here recently then you will know already: our new site is finally online, live for everyone!

The intent was to revamp our site into a place that perfectly aligns with both our community and our business goals, and I think we have succeeded at doing so - but I will let you be the judge of that.

Thanks to everybody in the team for making this possible. To all our visitors I would say: enjoy!

It has been taking months since we started it, but our new website will be online very soon now. We are currently doing the last bits of work to get it ready…

What makes our new site interesting is our geographically dispersed team that has been working on it:

• The content and PDF goodies were written in Canada
• The overall site design was done in Belgium
• The content management support - a wiki platform - was (and still is) being done in Germany

From the inception to the finish, this has been a great deal of fun (and work!) and it is a very exciting way of doing things! This is yet another example of how far you can get with a work tracker (like fogbugz), a wiki and skype;-)

I was at Devoxx (formerly Javapolis) today. Besides wandering around in the lobby (I prefer to talk to people there rather than listening to talks), the only presentation I attended was on the SpringSource dm Server. Joris Kuipers did a nice job on explaining how the OSGi modules work (I think I got it - more or less;-)

Tomorrow (Thursday) I will be there too - so if you are around just make sure to say hi!

A lot of the hype in "Extreme Transaction Processing (XTP)" is fail-over. When Oracle bought Coherence (a Tangosol product), they essentially got an XTP solution for database access.

As Cameron Purdy notes here, this now allows Oracle to provide a degree of XTP failover.

Now guess what: with Atomikos TransactionsEssentials you get:

• Transactional robustness for nothing, and
• failover for free

How? Just do the following:

1. queue requests in JMS
2. process them by a cluster of competing consumer processes
3. use Atomikos TransactionsEssentials to ensure that each message is processed exactly once, without duplicates or message loss

By the semantics of queues, this architecture will give you failover. By the semantics of transactions, this will give you exactly once. Since the requests can be queued by any source, this is multichannel. Everything is commodity infrastructure. This is very easy to scale: just add another process.

In summary, this is XTP of the highest degree:-)

Working for Atomikos, I use two-phase commit a lot. While I don't want to claim that it is a solution to all problems, I do find it frustrating to hear people proclaiming that they don't use it because it doesn't scale (or some other reason).

Take, for instance, Werner Vogel's talk about the Amazon architecture. Once again, two-phase commit is rejected as a viable solution/technology. Once again, I disagree.

Let me illustrate my point with an example of what really happened to me recently - after ordering a book at Amazon (ironically;-). I can give similar examples with airline ticket reservations but those will have to wait until later…

So what happened really? Well, I ordered a book that I really wanted to have. I ordered it online at Amazon… All went well, I checked out and paid by VISA. However, that is where things started to go wrong: while waiting for the book to be delivered, I suddenly get an email from Amazon saying that… my order has been canceled!

Canceled? Yes, but not in a way you would think: I still had to pay for the delivery by DHL (sorry, what is that?!). Yes sir, DHL claimed they had found nobody present at the delivery address. The delivery was at our office address, so it is very unlikely that nobody be there in the first place. Moreover, any courier service I know will leave a note that they passed by and at least settle for an alternative delivery. Not this time.

My conclusion? DHL did not arrive at my place. On the Amazon order tracking page, my order had not even left Germany (to be delivered where I live, in Belgium).

Now what will I remember? I will remember that Amazon let me down, either directly or via DHL. I will also remember to be very suspicious about people who say they don't need two-phase commit. Two-phase commit comes down to ensuring agreement between the different parties involved in a transaction. Clearly, there was no such thing in my case.