Question

I have a database table that I use as a queue system, where separate process that talk to each other create and read entries in the table. For example, when a user initiates a search an entry is created, then another process that runs every second or two will pick up that new entry, update the status and then do a search, updating the entry again when the search is complete. This all seems to work well with thousands of searches per hour.

However, I have a master admin screen that lets me view the status of all of these ‘jobs’ but it runs very slowly. I basically return all entries in the table for the last hour so I can keep an eye on what’s going on. I think that I am running into lock issues of some sort. I only need to read each entry, and don’t really care if it the data is a little bit out of date. I just use a standard ‘Select * from Table’ statement so maybe it is waiting for other locks to expire before returning data as the jobs are constantly updating the data.

Would this be handled better by a certain kind of cursor to return each row one at a time, etc? Any other ideas?

Thanks

Answer 1

If you really don’t care if the data is a bit out of date… or if you only need the data to be 99.99% accurate, consider using WITH (NOLOCK):

SELECT * FROM Table WITH (NOLOCK);

This will instruct your query to use the READ UNCOMMITTED ISOLATION LEVEL, which has the following behavior:

Specifies that dirty reads are allowed. No shared locks are issued to
prevent other transactions from modifying data read by the current
transaction, and exclusive locks set by other transactions do not
block the current transaction from reading the locked data.

Be aware that NOLOCK may cause some inaccuracies in your data, so it probably isn’t a good idea to use it throughout the rest of your system.