• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JTA

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If an EJB is using JTA to manage transaction, does it matter whether your JDBC connection is set to auto commit true or false, or does it still require the auto commit flag set to false?
Thanks
Eric
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
U r not supposed to call autoCommit() method.

Originally posted by Eric Lim:
If an EJB is using JTA to manage transaction, does it matter whether your JDBC connection is set to auto commit true or false, or does it still require the auto commit flag set to false?
Thanks
Eric

 
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, you should not try to manage the transaction using the Connection funcionallity as the javax.transaction.UserTransaction interface already controls the scope of the transaction.
You should also notice that you don�t necessarily have the Connection class to use the UserTransaction interface, you can always get the UserTransaction reference using a method from the EJBContext interface
 
Ranch Hand
Posts: 1309
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Even though bean-managed demarcation makes you responsible for starting and completing a transaction, the container still handles the enlistment of resources in a transaction. You have to control all transaction demarcation through the UserTransaction API and not using any API provided by a resource manager. For example, if you are accessing a database or a JMS session, you cannot call commit or rollback on a java.sql.Connection or a javax.jms.Session. Such an attempt would interfere with the coordination provided by the transaction manager.
 
Eric Lim
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for all your reply. I understand that you don't have to and must not manage the transaction yourself using connection.commit() etc. if you are using JTA.
The reason I asked whether you still have to set the auto commit to false in your connection to make JTA work is because I noticed that if I don't set the auto commit to false in my connection, and assuming I am inserting a record to a table, the record gets inserted straight away even if I have not yet reached the commit statement in my UserTransaction. I did this on a debug mode by stepping through the code. Maybe I missed something?
thanks
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What application server and database are you using? And how did you obtain the database connection?
Kyle
 
Author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eric Lim:
The reason I asked whether you still have to set the auto commit to false in your connection to make JTA work is because I noticed that if I don't set the auto commit to false in my connection, and assuming I am inserting a record to a table, the record gets inserted straight away even if I have not yet reached the commit statement in my UserTransaction. I did this on a debug mode by stepping through the code. Maybe I missed something?


When you say that you verified it by stepping through the code, does that mean you used queried the database as part of the same transaction that you used to insert the record? Remember that, even if you have not committed the transaction, the view of the data in the database from the standpoint of that transaction will make it seem like the insert has been committed. In fact, the insert is not visible to others (i.e., not really in the database) until the commit is processed. A better way to check when the insert happens is to step through your code while also querying the database with a separate tool (i.e., SQL*Plus or DBAcecss or your own home-grown client) which connects using a separate connection and transaction.
 
Eric Lim
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Kyle
I'm glad that you asked because I think that's probably where my problem is. At the moment I am using Microsoft Access as a proof of concept and using odbc-jdbc bridge. For some reason I couldn't get a connection successfully from the DataSource using JNDI so I'm using DriverManager.getConnection(). I'm sure I have read somewhere that you have to get the connection from the DataSource using JNDI to make JTA work. Do you think this is where the problem is? By the way, I'm using iPlanet as the application server.
And regarding stepping through the code and viewing the record, I'm actually using MS Access itself to look at the record so they shouldn't be in the same transaction context as my code.
thanks
 
Eric Lim
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
I have a question regarding J2EE compliance and Transaction Management in an EJB. Does the EJB 1.1 specs explicitly require that we have to use JTA to demarcate and manage transactions in a bean-managed transaction? That is, if we use JDBC to manage a transaction (using the Connection object commit/rollback) in an EJB, does it make our EJB non-J2EE compliant?
This is very important question for us and I really appreciate any feedback from you on this.
Thanks
eric
 
JiaPei Jen
Ranch Hand
Posts: 1309
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In a session bean with bean-managed transactions, it is possible to mix JDBC and JTA transactions. This practice is not recommended because it could make your code difficult to debug and maintain.
I hope that experts could step in if there is a mistake in my statement.
 
Eric Lim
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, JiaPei. I guess I need the most definitive answer to this but I also welcome any opinion especially if you have done a non-trivial project that use JDBC from EJB to manage transactions.
 
JiaPei Jen
Ranch Hand
Posts: 1309
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is what I found in the J2EE BluePrints:

An enterprise bean should not invoke resource manager-specific transaction demarcation API methods (like java.sql.Connection.commit(), java.sql.Connection.rollback(), etc.) while within a transaction.

 
I'm full of tinier men! And a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic