Women in Technology

Hear us Roar

  J2EE Without the Application Server
Subject:   Some room for improvement...
Date:   2006-02-09 13:02:00
From:   jhannes
Hi, Guy

It's great to see more people write about Spring as a partial replacement for a heavy application server. I especially liked the fact that you showed the use of a JTA-provider outside the EJB-container.

However, your article would've been much improved, if you had used the Spring JdbcTemplate, JmsTemplate and AbstractTransactionalSpringContextTest classes. (And the XML configuration could've been more compact with the new compact <property name="..." ref="..." />-syntax and good use of autoproxy).

Also: I found one glaring error in your article. In the case that one of my developers read the article, I have to put the record straight :-): "Without XA, your application will not be recoverable after a crash or restart". This is of course a bit inexact. Databases (and Spring!) support transactions without XA, but not distributed transactions. As long as you only have one data source, you don't need XA for recoverability.

Lastly: I would be very interested in hearing more about out-of-container JTA support (as in Atomikos). For example: To what extent can you keep the same configuration in an out-of-container and in-container environment? What options are available for out-of-container JTA? Under what licenses.


Full Threads Oldest First

Showing messages 1 through 4 of 4.

  • Some room for improvement...
    2006-02-10 01:37:51  guypardon [View]


    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 http://www.atomikos-support.com/forums/viewtopic.php?t=108 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 (http://www.atomikos.com) 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,

    • 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?

      • Alternative JTA-enabled datasource?
        2006-09-07 23:25:02  guypardon [View]


        The Atomikos product used in this article is now available as open source. Check out http://www.atomikos.com for more information.

    • 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...