We are currently re-organising our developer support model in the following ways:

• Developer support tickets are no longer offered in isolation but rather in packets of 4
• This formula has been renamed to developer access

There are a number of reasons for doing this, but the most important one is that we want to avoid cumbersome discussions about whether a support question is actually one, two or more tickets: every time this has happened in the past, our customers were unhappy because they needed to go back to their management and ask for a budget one more time. Our new formula represents a compromise that should cover most scenarios with just one purchase.

The new formula should be online soon.

The newest product roadmaps for Atomikos are available here...

All feedback is welcome!

With the current (2008-2009) recession, cost cuts and commoditization of both software and hardware, the end result seems to be converging towards the state predicted by the late Jim Gray during his Turing Award speech in 1998:

"Cheap and buggy. Sometimes it will work, sometimes not, and nobody will really know why".

Given the perspective of such a world, it seems like some precautions are justified. Since it can't be repeated often enough, here is the Atomikos view on how to alleviate all this:

• Use our transaction technology to avoid data inconsistency after a failure or crash. It acts like an insurance, really: you don't need it when things are fine, but when things are turning bad you're sure glad to have one!
• Use queuing to your advantage. Avoid depending on the availability of a remote service by delaying requests until they can be performed (i.e., when the remote service is up).
• Add virtually unlimited scalability while you're at it…

The combination of technologies and techniques outlined here will increase your reliability while decreasing costs. You save on expenses by using commoditized hardware and software. You also save on man-hours of development because our products will allow you to focus on the happy path (failure handling is automated to a large part by our software). This significantly decreases the complexity of the workflow your developers have to code, maintain and debug. Less code in turn means less bugs, so this again increases reliability. Isn't that beautiful?

Hi all,

For those of you who are going to the SOA symposium in Rotterdam next month: if you're interested in meeting Atomikos staff members then be sure to check for Guy - who will be attending the conference.

Regards, Guy (himself;-)

Due to popular demand, we now also have a maven repository online. This means our community can pick up new releases without requiring re-registration every time (although we don't yet synchronize with the central, well-known public repositories).

Interested in finding out more? Detailed instructions are included in the download confirmation email - so next time you register should be the last time…