Welcome to Atomikos
Wed, 15 Jul 2015 14:28:19 +0000 GuyPardon
Our customers regularly ask for disaster recovery options in combination with our JTA/XA implementation. While looking around for background information, we realised that there is little information waiting to be found, so we figured we’d study it ourselves and share our findings with you. To get the discussion started, this is the first part in a series on disaster recovery - introducing the reader to the problem of disaster recovery and XA environments. Later parts will discuss a number of possible solutions with varying degrees of recoverability.
Let’s start with setting the context. The situation we have in mind is one where requests are queued for processing by the application. A simplified description of what the application does is the following:
We’re assuming that all of the resources involved (message brokers and database) are XA-capable. We’re also assuming that the transaction manager keeps transaction log files for recovery.
In this setting, disaster recovery typically involves an active/passive combination of datacenters, more or less kept in-sync in some way or another.
The problem is simple: given that the two datacenters must be kept in-sync, how do we do this? The naive answer would be database replication, with some vendor-specific replication mechanism that pushes updates from the active database to the passive one. However, in our context this is not sufficient: the database is not the only component maintaining application state. There are also the message broker(s) and the transaction log file to take into account. Database replication alone will not cut it, because you would only have the database state replicated to some extent, not the queued requests in the broker, nor the state of ongoing transactions.
The ideal solution
Ideally, you would want to have everything replicated synchronously: the database, the broker, the transaction logs and the ongoing XA sessions in each resource. That way, the passive site would be a complete mirror of the active one.
The real world
Unfortunately, the real world is far from ideal and the ideal solution is hard to obtain: you would need a perfectly replicated vendor setup for the broker, the database and the file system. Moreover, the replication in all these systems should work in ‘lock-step’ way so that the combination of replicated transaction state at the passive site is ‘consistent’ with the distributed transactions happening at the active site - putting even more constraints onto the system. And this is where it starts getting really difficult to implement: even the most sophisticated replication systems we know of will fail to offer replication of ongoing XA sessions, which makes it unrealistic to assume that this is ever going to be possible (and if it were possible, it would surely be the most expensive system configuration you can think of).
So here we are: we’ve outlined the problem! Stay tuned for the sequel, where we’ll discuss a first solution.
Wed, 21 Jan 2015 10:24:28 +0000 GuyPardon
What better way to start the new year than with a glimpse of what the future will bring for Java?
In this interview, Eberhard Wolff discusses why he thinks the application server is dead.
It’s good to see that after more than 8 years after we introduced it, our jee without application server paradigm shift is more relevant than ever! And as usual, we’re here to give you the transactions you need without the application server.
UPDATE: Eberhard also has an article on this here…
Mon, 08 Dec 2014 08:35:25 +0000 GuyPardon
Another great independent article on how the app server is disappearing, with the ESB going along:
Interested in going one step further and moving into implementation? Download our JEE without application server vision to see some concrete tips on how this can work in Java…
Mon, 17 Nov 2014 18:27:53 +0000 atomikos
A few weeks back we’ve been sending around this poll via our newsletter subscriber base. We got a lot of answers so I will not go into every single one of them (and we can’t send individual replies, BTW, because the survey was anonymous). However, here is a distillation of the results, and our comments / questions to each:
Business model: some respondents suggested we look into a new business model like JBoss, for instance. We don’t really understand why, because what we are doing is about the same thing as what Red Hat is doing? We’re curious to learn though, if anybody wants to clarify…
Integrations: a lot of people requested more built-in integration with third-party platforms. We’re certainly doing that: we’ve recently added Tomcat and are working on more things to come… Thanks for that!
Documentation: We always need more documentation. Somebody also suggested that we restructure our existing docs and offered to help. If you are that person, please email us (plenty of contact addresses on our website). Thanks!
Performance: We should do more benchmarking and publish / compare the results. That is certainly true, but we found that it depends so much on your configuration (not ours) that it is hard to come to a general conclusion. It just depends…
Again, we were not able to contact individual respondents so our interpretation and conclusion could be wrong. If that is the case, and you feel misunderstood (or just want to help) then please get in touch via our website.
Tue, 30 Sep 2014 19:54:43 +0000 GuyPardon
Microservices are all about splitting up responsibilities of your domain’s bounded context into several HTTP-like services, deployed independently. So essentially it means splitting up process boundaries across different services - away from the monolith…
What is the consequence for your business transactions? In some (though not all) cases you may need some notion of transaction management but you can’t resort to XA or classical distributed transactions in the REST world…
So what are your options? Our newest API, TCC for REST, allows light-weight BPM and transaction management across independent REST services. Interested in learning all about it? Find out for yourself here (requires registration).