J2EE Without the Application Server
Subject:   Some room for improvement...
Date:   2006-02-10 01:37:51
From:   guypardon
Response to: Some room for improvement...


Thanks for your hints.

I agree that the Spring templates can make things easier still. However, I didn't use them to make it easier for non-Spring people to follow.

Another reason why I left them out is that many project managers are still reluctant to "non-standard" approaches and so I wanted to make the explicit dependencies on both Spring and the JTA minimal (I am sure that at some point in time at least one person will object here that Spring is not standard :-).

In case of only 1 connector you can indeed do without XA (my presentation on TheServerSide mentions that explicitly, see the resources section for the URL). You are right to confirm this fact, especially if it is not clear from the context of the article.

In the article we need XA because we have 2 connectors; I think I also say that somewhere else in the text. In fact, readers who want more information can have a look at in our forums.

When it comes to configuration changes in and out of the container: our same product works in both cases. The only recommended change would be to use our J2eeUserTransaction and J2eeTransactionManager implementation classes (instead of the ones used in this article). This is: assuming that you are still using our connectors for JMS and JDBC...

For the licenses: our website ( has the latest policies (under the 'buy' section). If you have detailed requirements/questions that are not answered there, just send me an email.

Warm regards,


Main Topics Oldest First

Showing messages 1 through 2 of 2.

  • Alternative JTA-enabled datasource?
    2006-02-14 02:41:48  ws_developer [View]

    Many thanks for this great article. Are there any good alternative JTA-enabled datasources? I mean opensource alternatives please?

  • Some room for improvement...
    2006-02-10 17:07:01  jhannes [View]


    Thanks for the pointers on Atomikos. I will consider it if the opportunity arises. We're doing technical testing of our current app server. If we run aground, I will take up the offer to contact you to see whether Atomikos could be an option.

    Regarding the templates, I have heard your argument before, but I think it is faulty. Raw JDBC code is so verbose and error prone that not using something like DbUtils or Spring-DAO is only to ask for needless pain. I would much rather wrestle with some ignorant manager than with JDBC. I also think that when demonstrating Spring, the increase in clearity and compactness is worth the effort of explaining JdbcTemplate.

    But maybe that is just me, I just think JdbcTemplate is the closest thing you can get to a free lunch. :-) That's just my view, though. It's a pretty interesting discussion, deciding what tools to use...