Prev: FREE SOFTWARE DOWNLOAD
Next: Migrated From v7 => v9 ... and Now Can't Use Semi-Colons inStrings?
From: contactrajib on 27 Jun 2008 11:31
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
From: peter on 28 Jun 2008 02:19
On Jun 28, 1:31 am, contactra...(a)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
> 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

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.
 | 
Pages: 1
Prev: FREE SOFTWARE DOWNLOAD
Next: Migrated From v7 => v9 ... and Now Can't Use Semi-Colons inStrings?