Women in Technology

Hear us Roar



Article:
  Bean-Managed Transaction Suspension in J2EE
Subject:   Point?
Date:   2005-07-21 21:45:02
From:   hbarua
IMHO, the reason there was a UserTransaction interface was to clearly separate out the roles and responsibilities of BMTs and CMTs. Forcibly trying to extract the TM probably indicates that the app is not configured properly for transactions. If the J2EE spec does mandate exposing the TM in future versions of the spec that would of course be useful to frameworks like Spring (and also most of the OR mapping tools which use transactions). The tricks described here would just lead to non portable applications, apart from leading to possible inconsistencies.
Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • Point?
    2005-07-22 06:34:10  maximdim [View]

    I'm not advocating for this approach to replace CMT, by all means if CMT is sufficient for particular task one absolutely should prefer to use it over BMT. But in real life there are some (albeit rare) situations when you have to have flexibility of BMT in your code and also may have a legitimate reason to suspend/resume transactions. This article explains exactly that - how to do it when you need it.
    Moreover I hoped to bring a little bit more light how Spring makes 'transactional proxies' functionality work, because I think it's important for developers to understand internal 'kitchen' of framework they're using and possible problems/limitations it imposes.
    J2EE spec is not a dogma, and looking up TM doesn't make your code less portable than say using container-specific deployment descriptors. Even so in this article sample code to lookup TM intentionally simplified, there is a perfectly legal way to do it without introducing dependencies on any container-specific classes so your code would work in any container (see Spring sources for details if interested).