db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prashant Bhagat" <Prashant.Bha...@Sun.COM>
Subject RE: ERROR 40XL2: A lock could not be obtained within the time requested.
Date Wed, 29 Nov 2006 02:14:25 GMT
Update: I think the problem could be due to the fact that I'm aborting
only the Appserver - the Derby database is always running. So the Derby
database never knows that T1 is no longer valid and that it should abort
the transaction after a timeout. The XAResource has a method
setTransactionTimeout(int i) to specify timeouts for transactions.

 

Unfortunately the class org.apache.derby.client.net.NetXAResource does
not seem to support this functionality. I changed my code to set the
timeout of 60 seconds, but the getTransactionTimeout() returns 0. Is my
understanding correct? Is there any other way to specify an XA
transaction timeout.

 

TIA

Prashant

 

 

 

 

-----Original Message-----
From: Prashant Bhagat 
Sent: Monday, November 27, 2006 8:33 PM
To: 'derby-dev@db.apache.org'
Subject: ERROR 40XL2: A lock could not be obtained within the time
requested.

 

Hi,

I'm using the Derby database bundled with Sun Java System Application
Server 9. My application writes to the database using XA and well as
non-XA connections. For XA as well as non-XA , the application directly
instantiates the DataSource and gets the connection. The application
manages its own transactions using the TransactionManager, that is, it
does its own enlist/delist (for XA), etc.

 

I run into this error ERROR 40XL2: A lock could not be obtained within
the time requested, for the case outlined below.

 

There are two transactions T1 (XA) and T2 (Non-XA). They have two common
tables that they update.

 

1.      Start T1 and write to the database

2.      Abort appserver (note: T1 is still in progress, that is, commit
has not been called)

3.      Start appserver

4.      Do T2 - exceptions (ERROR 40XL2: A lock could not be obtained
within the time requested.)

 

Doing T1 again does not result in any exceptions. 

 

One more thing: When the appserver is started in 3, the application does
not register an XAResource with the TransactionManager. So no XA
recovery takes place. That should not matter for this case since the
appserver was aborted before the Transaction is in the prepared state.

 

Thanks

Prashant

 

 

 

 

 

 

 


Mime
View raw message