aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Use of resource-manager specific transaction demarcation API Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Use of resource-manager specific transaction demarcation API" Watch "Use of resource-manager specific transaction demarcation API" New topic
Author

Use of resource-manager specific transaction demarcation API

Bane Devrnja
Greenhorn

Joined: Feb 02, 2012
Posts: 2
Accordinong to EJB 3.0 specification: While an instance is in a transaction, the instance must not
attempt to use the resource-manager specific transaction demarcation API (e.g. it must not invoke the
commit or rollback method on the java.sql.Connection interface or on the
javax.jms.Session interface) In 13.3.3 of Specification.
I tried one example - where in BEAN managed transaction I included java.sql.Connection.commit() - created Stateless bean in NetBeans as EE5, deployed on Glassfish 3.1 and container did not complain?

Also, there is no such restriction on using java.sql.Connection.commit() for beans with container transaction managed transactions mentioned in specification?
Thanks
Branislav

Here is the Stateless bean:


@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class MySession implements MySessionRemote {
@Resource(name = "SAMPLE")
private DataSource SAMPLE;

//
@Resource UserTransaction utx;

//gore je novi kod
@Override
public String getResult() {
return "This is my Session Bean";
}

public void doSomething() {
try {
Connection conn = SAMPLE.getConnection();
Statement stmt = conn.createStatement();
String q = "select * from BOOK";
String up = "update BOOK set PRICE = PRICE + 1";
utx.begin();
int num = stmt.executeUpdate(up);
System.out.println("num: "+num);
ResultSet rs = stmt.executeQuery(q);
//is conn.commit() legal?
conn.commit();
String name = null;
int price = 0;
while (rs.next()) {
name = rs.getString(2);
price = rs.getInt(3);
System.err.println(name+" , "+price);

}

utx.commit();
} catch (SQLException ex) {
Logger.getLogger(MySession.class.getName()).log(Level.SEVERE, null, ex);

} catch (Exception ex) {
Logger.getLogger(MySession.class.getName()).log(Level.SEVERE, null, ex);
}
}
// Add business logic below. (Right-click in editor and choose
// "Insert Code > Add Business Method")

}
Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
    
    1
Hi!
The restriction is not there because it will not work, it is there because the EJB container is supposed to manage transactions for you.
If you use the resource-manager specific transaction API, you are effectively bypassing the EJB container's transaction management.
Thus: Use the transaction-demarcation supplied by the EJB container if you are using EJBs.
Best wishes!


My free books and tutorials: http://www.slideshare.net/krizsan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use of resource-manager specific transaction demarcation API
 
Similar Threads
JTA
My Study Notes
Error when deploying an EAR on JBoss 5.1.0
Problem integrating hibernate & EJB 3
Passing Params