Question

Intermittently in our app, we encounter LockTimeoutExceptions being throw from SQL CE. We’ve recently upgraded to 3.5 SP 1, and a number of them seem to have gone away, but we still do see them occasionally. I’m certain it’s a bug in our code (which is multi-threaded) but I haven’t been able to pin it down precisely. Does anyone have any good techniques for debugging this problem? The exceptions log like this (there’s never a stack trace for these exceptions):

SQL Server Compact timed out waiting for a lock. The default lock time is 2000ms for devices and 5000ms for desktops. The default lock timeout can be increased in the connection string using the ssce: default lock timeout property. [ Session id = 6,Thread id = 7856,Process id = 10116,Table name = Product,Conflict type = s lock (x blocks),Resource = DDL ]

Our database is read-heavy, but does seldom writes, and I think I’ve got everything protected where it needs to be.

EDIT: SQL CE already automatically uses NOLOCK http://msdn.microsoft.com/en-us/library/ms172398(sql.90).aspx

Answer 1

I just realized that 3.5 SP1 includes new information in the exception that let me pin in down.

SQL Server Compact timed out waiting for a lock. The default lock time is 2000ms for devices and 5000ms for desktops. The default lock timeout can be increased in the connection string using the ssce: default lock timeout property. [ Session id = 6,Thread id = 7856,Process id = 10116,Table name = Product,Conflict type = s lock (x blocks),Resource = DDL ]

I was able to identify that it was occuring when were trying to drop an existing table that must have open connections to it.