Discussions

EJB design: JTA, JDBC - Totally Confused!

  1. JTA, JDBC - Totally Confused! (1 messages)

    Hi everyone.

    I am trying to get a thorough understanding of the way JTA and JDBC interact and are related. Some typical comments that I have seen in various J2EE literature have left me confused. These statements include:

    1) "The J2EE platform reqiuires both the JDBC 2.0 Core API, and the JDBC 2.0 Extension API" - I note that the Extension API supports distributed transactions - i.e. 2 phase commit

    2) "Currently, the J2EE platform is only required to support access to a single JDBC database within a transaction (multiple connections to the same database are allowed). It is not required to support access to multiple JDBC databases within a singe transaction. "

    I note - Does this latter statement not contradict the requirement to support JDBC2.0 extensions which supports distributed transactions?

    3) With regard to JTA transactions -- " Applets and client applications MAY OR MAY NOT be able to directly access a UserTransaction object depending on the capabilities provided by the container"

    This confuses me - By default, J2EE does not require that applets and clients be able to control transactions explicitly themselves - That's fine. But then it is suggested that a J2EE provider has to "do domething special" to allow direct access to JTA from these clients - But Why? Is it just not a case of jar-ing the JTA implementation that's available on the server and including it in the clien't classpath, or in the codebase for the applet? Is this the case?

    So all in all, these 3 statements confuse me -

    a) What exactly is JTA?

    b) What exactly does JTA provide that JDBC doesn't/can't? After all, JDBC does support transactions!

    c)If an EJB container is using a JDBS driver that supports distributed transactions, is that enough for a distributed transaction, or do we need JTA as well on top of this?

    I look forward to your responses

    Thanks

    Paddy
  2. JTA, JDBC - Totally Confused![ Go to top ]

    1) "The J2EE platform reqiuires both the JDBC 2.0 Core API, and the JDBC 2.0 Extension API" - I note that the Extension API supports distributed transactions - i.e. 2 phase commit

    *** Yes, the extension API supports two phase commits.


    2) "Currently, the J2EE platform is only required to support access to a single JDBC database within a transaction (multiple connections to the same database are allowed). It is not required to support access to multiple JDBC databases within a singe transaction. "


    *** This is most definitely NOT true, you can update multiple databases in one transaction. J2EE does not suport nested transactions, or the distributed diamond (local diamonds are supported), but that doesn't mean you can't transact across multiple data stores.

    For instance, ignoring databases completely, you may want to transact between updating a database and publishing something to a JMS queue. I.e. Don't publish the event unless the database is updated, and don't update the database unless the event publishes. Classic atomic operation really.

    Not only that, but you can do this.

    Client -> Bean 1.
    Bean 1 -> Create transaction
    Bean 1 -> Call bean 2
    Bean 2 -> Update database
    Bean 1 -> Call bean 3
    Bean 3 -> Update another database
    Bean 1 -> Commit transaction.

    This is all supported according to the spec (I am referring to 1.1 but I am pretty sure it's in all of them.)

    So, not only does it support updates to multiple databases (Thus requiring JTA, not just JDBC extensions) but it supports a variety of different ways of doing this. The best description of all this is actually in chapter 11 of the EJB 1.1 spec which gives several examples which make it pretty clear.


    I note - Does this latter statement not contradict the requirement to support JDBC2.0 extensions which supports distributed transactions?

    *** Even if the second statement is right, it's not a contradiction. Supports does not mean that there are no restrictions on how you can use them within the EJB spec. For instance, no support required as of 1.1 for the distributed diamond.

    3) With regard to JTA transactions -- " Applets and client applications MAY OR MAY NOT be able to directly access a UserTransaction object depending on the capabilities provided by the container"

    *** Firstly, J2EE only mandates the the javax.transaction.UserTransaction interface be supported. The rest of the interfaces do not have to be specifically supported for application developer use. J2EE doesn't make any statements about the clients as far as I am aware. However, it is possible to set the transaction requirements on a bean to TX_REQUIRED which would imply that the "client" must pass in a transaction context to the bean.

    Most people tend to have this transaction type on entity, or other beans not directly accessible from the client. The client access beans tend to take on the role of creating the transaction context.

    However, the implication of the TX_REQUIRED declaration is that the client could pass in a transaction context. There's no reason the client can't get one of these from JNDI in the same way they look up bean references.



    This confuses me - By default, J2EE does not require that applets and clients be able to control transactions explicitly themselves - That's fine. But then it is suggested that a J2EE provider has to "do domething special" to allow direct access to JTA from these clients - But Why? Is it just not a case of jar-ing the JTA implementation that's available on the server and including it in the clien't classpath, or in the codebase for the applet? Is this the case?

    *** Getting a UserTransaction object from JNDI is the same as looking up a bean reference, nothing particularly special required.


    So all in all, these 3 statements confuse me -

    a) What exactly is JTA?

    *** A set of interfaces for governing transactions using two phase commit. Only the UserTransaction interface must be directly exposed by the EJB container.

    b) What exactly does JTA provide that JDBC doesn't/can't? After all, JDBC does support transactions!

    *** JDBC only covers databases, JTA covers anything that supports it, in other words anthing XA compliant. JDBC extensions are what makes JDBC support 2 phase commit. JTA is what lets you, the developer, use the 2 phase commit functionality.

    c)If an EJB container is using a JDBS driver that supports distributed transactions, is that enough for a distributed transaction, or do we need JTA as well on top of this?

    *** You should use JTA, by pulling a UserTransaction off JNDI and using it. Don't use commit() or rollback() against the JDBC classes, use begin() commit() and rollback() against the transaction object.

    Hope that helps

    Chz

    Tony