File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes JTA Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "JTA" Watch "JTA" New topic
Author

JTA

Eric Lim
Greenhorn

Joined: Apr 01, 2002
Posts: 19
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
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

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


Groovy
Marcos Maia
Ranch Hand

Joined: Jan 06, 2001
Posts: 977
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
JiaPei Jen
Ranch Hand

Joined: Nov 19, 2000
Posts: 1309
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

Joined: Apr 01, 2002
Posts: 19
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
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
What application server and database are you using? And how did you obtain the database connection?
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Roger Thornhill
Author
Greenhorn

Joined: May 15, 2002
Posts: 25
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

Joined: Apr 01, 2002
Posts: 19
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

Joined: Apr 01, 2002
Posts: 19
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

Joined: Nov 19, 2000
Posts: 1309
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

Joined: Apr 01, 2002
Posts: 19
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

Joined: Nov 19, 2000
Posts: 1309
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: JTA