I have a situation where one of the app server thread is executing an
update statement on A record and at the same time another thread is
trying to read it by executing a select query. Now we are seeing
timeouts - Update query is holding the lock and the select statement
is timing off.
Now my question , how can I design this select statement so that it
doesn't wait for this update to be commiitted - I do not want to run
it with UR since it will allow dirty reads -
The lock is acquired via the following statement: UPDATE SIALRFCDATA
SET BLOBDATA=?, CREATED_DATE=?, FIELD1=? WHERE ORDERS_ID=? AND
TRANSACTION_TYPE=? AND RECORD_TYPE=?
The select query
SELECT ORDERS_ID, TRANSACTION_TYPE, RECORD_TYPE, CREATED_DATE,
MARKFORDELETE, CDATA, BLOBDATA, FIELD1, FIELD2, FIELD3, FIELD4 FROM
SIALRFCDATA WHERE ORDERS_ID = ? AND TRANSACTION_TYPE = ? AND
RECORD_TYPE =
Thanks
Rajib
peter - 28 Jun 2008 07:19 GMT
On Jun 28, 1:31 am, contactra...@yahoo.com wrote:
> I have a situation where one of the app server thread is executing an
> update statement on A record and at the same time another thread is
[quoted text clipped - 20 lines]
>
> Rajib
If there is unique index access, no lock escalation, no next key
issues and appropriate commits plus the rows are different there
should be no issue unless there is an issue with RI and supporting
indices. Add "for read only" to the select as it reduces the lock
level. DB2 is conservative with its locks an will assume an intent to
update unless this is not clear from the SQL statement. Check that it
isn't a repeatable read issue. The read only will help with this.