Women in Technology

Hear us Roar



Article:
  Bean-Managed Transaction Suspension in J2EE
Subject:   Point?
Date:   2005-07-22 06:34:10
From:   maximdim
Response to: Point?

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).
Main Topics Oldest First

Showing messages 1 through 3 of 3.

  • Point?
    2005-07-22 09:13:56  hbarua [View]

    >> This article explains exactly that - how to do >>it when you need it.
    Yes it makes sense from that perspective. Thanks for pointing it out.

    >>I think it's important for developers to >>understand internal 'kitchen' of framework >>they're using and possible problems/limitations >>it imposes.
    Absolutely agree with this.


    >>J2EE spec is not a dogma, and looking up TM >>doesn't make your code less portable than say >>using container-specific deployment descriptors.


    I didn't say it's a dogma - the nonportability can come about because certain appservers might have restrictions on the methods you can use on the exposed Transaction Manager. As long as it's not a standard one can never be safe in assuming it.
  • Re: Point?
    2005-07-22 09:12:51  hbarua [View]

    >> This article explains exactly that - how to do
    >>it when you need it.
    Yes it makes sense from that perspective. Thanks for pointing it out.

    >>I think it's important for developers to
    >>understand internal 'kitchen' of framework
    >>they're using and possible problems/limitations
    >>it imposes.

    Absolutely agree with this.


    >>J2EE spec is not a dogma, and looking up TM
    >>doesn't make your code less portable than say
    >>using container-specific deployment descriptors.

    I didn't say it's a dogma - the nonportability can
    come about because certain appservers might have
    restrictions on the methods you can use on the
    exposed Transaction Manager. As long as it's not a
    standard one can never be safe in assuming it.
  • Point?
    2005-07-22 09:10:01  hbarua [View]

    >> This article explains exactly that - how to do >>it when you need it.
    Yes it makes sense from that perspective. Thanks for pointing it out.
    >>I think it's important for developers to >>understand internal 'kitchen' of framework >>they're using and possible problems/limitations >>it imposes.
    Absolutely agree with this.

    >>J2EE spec is not a dogma, and looking up TM >>doesn't make your code less portable than say >>using container-specific deployment descriptors.
    I didn't say it's a dogma - the nonportability can come about because certain appservers might have restrictions on the methods you can use on the exposed Transaction Manager. As long as it's not a standard one can never be safe in assuming it.