• 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, java.sql.Connection.close()

 
Ranch Hand
Posts: 427
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's suppose that I have this method:
public void doUpdate() throws SQLException
{
java.sql.Connection conn;
java.sql.Statement stmt;
conn = getConnectionFromXADataSource();
// ...
stmt.executeUpdate(strSQLUpdate);
// ...
conn.close();
}

Also, suppose that "doUpdate" is executing in a JTA transaction:
public void processRequest()
{
UserTransaction tx;
// ...
tx.begin();
doUpdate();
tx.commit();
}

Does conn.close() interfere with the JTA transaction?
Should I remove "conn.close()" from doUpdate?
Would it be better for me to call conn.close() after
I call tx.commit() ?

http://java.sun.com/products/jta/
http://java.sun.com/products/jdbc/
 
Sean Sullivan
Ranch Hand
Posts: 427
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In other words...
Which technique is preferred?
Technique A:
conn.close();
...
tx.commit();
Technique B:
tx.commit();
...
conn.close()
 
Sean Sullivan
Ranch Hand
Posts: 427
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The JTA 1.0.1B specification states:
"The resource manager, once opened, is kept open until the resource
is released (closed) explicitly. When the application invokes
the connection�s close method, the resource adapter invalidates the
connection object reference that was held by the application and
notifies the application server about the close. The transaction manager
should invoke the XAResource.end method to disassociate the transaction
from that connection.
The close notification allows the application server to perform
any necessary cleanup work and to mark the physical XA connection
as free for reuse, if connection pooling is in place."
 
Sean Sullivan
Ranch Hand
Posts: 427
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the Websphere Application Server 5.0.1 InfoCenter (www.ibm.com):
[...] Applications should explicitly close connections
(note: the connection that the user gets back is really a connection handle) by calling close() on the Connection object.
[...]
If the application (or the container) calls close() (close) and there are no references (noOtherReferences) either by the application (application sharing) or by the transaction manager (NoTx - who holds a reference when the connection is enlisted in a transaction), the Connection object returns to the free pool.
If the connection was enlisted in a transaction but the transaction manager ends the transaction (txEnds), and the connection was a shareable connection (ShareableConnection), the connection closes and returns to the pool.
[...]
When the application calls close() on a connection, it is returning the connection to the pool of free connections; it is not closing the connection to the data store. When the application calls close() on a currently shared connection, the connection is not returned to the free pool. Only after the application drops the last reference to the connection, and the transaction is over, is the connection returned to the pool. Applications using unsharable connections must take care to close connections in a timely manner. Failure to do so can starve out the connection pool making it impossible for any application running on the server to get a connection.
When the application calls close() on a connection enlisted in a transaction, the connection is not returned to the free pool. Because the transaction manager must also hold a reference to the connection object, the connection cannot return to the free pool until the transaction ends. Once a connection is enlisted in a transaction, you cannot use it in any other transaction by any other application until after the transaction is complete.
[...]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic