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

Was it helpful?

Solution

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.

OTHER TIPS

In case anyone else comes across this page, I discovered another reason why this can occur. I had created a SqlCeTransaction to wrap various statements, and I accidentally didn't use that transaction on one of the statements. That was causing my Lock timeout message.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top