In an attempt to ‘increase performance’, many people will try to hack around in JMS - thereby falling into the idempotent receiver trap by checking for duplicate message receipt. The consequence: scalability actually degrades!
Archive for the ‘Uncategorized’ Category
Are you looking for an open source JTA/XA transaction manager for your web container?
Although web apps are not our mainstream business, some people do value Atomikos for their web apps.
See the jetty wiki for information on how to configure Atomikos within Jetty.
See this wiki page for configuration of Tomcat and Atomikos.
Check out this link: Red Hat Reacts to SpringSource Leadership and scroll down to the comments. Some (most?) of them seem to be acknowledging the Atomikos role in shaping the future of JEE…
This is a maintenance release that improves the JAX-WS handler configuration of the JAX-WS demo.
Download is recommended if you are interested in web service transactions…
As part of our ExtremeTransactions 3.6.1 release we have produced TransactionsEssentials 3.5.4 - a bug fix release for TransactionsEssentials.
The most important fixes in this release concern statement invalidation after transaction timeout and JMS/JNDI initialization improvements - both suggested by the community (for which thanks!)…
We now have our 3.6.1 release of ExtremeTransactions ready and online. This release includes a new and working JAX-WS demo performing a distributed transaction (where the commit scope reaches across web service calls) as well as several bug fixes. This release also includes a new version of the core: TransactionsEssentials 3.5.4
Feel free to check it out, all feedback is welcome!
Atomikos ExtremeTransactions supports web service transactions and also compensation-based TCC (Try-Confirm/Cancel) so your application/service is in control of what rollback or commit means.
According to more than one analyst we spoke to, web service transactions are supposedly incompatible with the loose coupling desired by SOA (Service Oriented Architecture), with the following being cited as the main reasons (read: problems):
- Any ‘hidden’ interactions (like out-of-band two-phase commit) are mistakenly perceived as a violation of the loose coupling and contract-based SOA design principles.
- As a result, a common problem is that a transactional service calls other services that are not transactional - and this going unnoticed. This becomes a problem when the desired outcome is rollback because those non-transactional services will commit their work right-away.
With Atomikos, these are all non-issues for the following reasons:
- Both the sender and receiver in a transactional (web) service interaction can specify (and enforce) their transaction preferences/assumptions by means of our intermediaries (’handlers’ in JAX-WS terminology).
- For instance, if a service (’A') expects another service (’B') to be transactional then it suffices to add our outgoing handler to the call chain at A. Thanks to the nature of our protocols, the calls to B will then carry the transaction context of A, and moreover the resulting SOAP return message from B will also indicate whether or not it has taken part in that transaction. If not, then the handler at A (inspecting the return message) will throw an exception to indicate the contract breach. So this guarantees the transaction contract being respected from A’s point of view.
- How about B? There the solution is similar: if B wants incoming calls to be transactional, it suffices to add a handler to the incoming call chain at B. This handler can be configured with similar transaction demarcation preferences as in JEE (REQUIRED, REQUIRES_NEW, …).
So it is really simple to enforce a transactional contract among services in a SOA, thanks to Atomikos. Compare this to the popular alternative of modelling rollback in the service workflow (which at least doubles the workflow complexity and makes the whole SOA initiative more brittle and less agile) and it becomes clear why we say: use Atomikos and focus on the happy path! (TM)
If you would like to try this out in practice, just check out ExtremeTransactions for yourself.
Sure you’ve heard about JEE… And if you know SCRUM then you probably also think that JEE is often counter-productive because of application-server issues.
Well, it doesn’t have to be like that: with Atomikos products and in combination with Spring and Hibernate, you can essentially ditch the application server and do everything inside a regular Java (JSE) virtual machine. The advantage: you can test what you deploy (nothing else is generated, nothing else is to be configured in XML files or anything). This actually redefines the meaning of test coverage: instead of testing your application classes, you can now also test most of the entire runtime as well, including the runtime jars. Add to that the tremendous improvement in turn-around time that Atomikos gives you, and you will never want to do agile in a different way again…
Exciting news for all those who have been waiting for this: we finally got our 3.6 release of ExtremeTransactions ready, including JAX-WS and SOAP support so that transactions can span multiple web services.
While we had support for web services in the past, this new release now incorporates JAX-WS support - meaning that you don’t have to resort to the older JAX-RPC any more.
In addition, we have made the web service support independent of the SOAP stack (any JAX-WS implementation should do).