Behavior:The OperationTimeoutException depends on the amount of records. Entities:
Init:
Exception:
Exception:
No Exception!!!
Exception Message:
|
Hello Teaman, During the investigation it was revealed that the exception is thrown only when there are nested sessions (and transactions) within one thread. Scenario with each session in a separate thread showed no problems. Seems that SQL Server CE provider has some thread affinity. However, we've found a bug in Thanks! |
Hello Teaman, I've found an interesting article concerning that case, please, check it out. The author suspects that due to large database fragmentation locktimeout exception is thrown and investigates the scenario in details. Hope that helps. Hallo Dmitri, thanks for the quick reply. Very interesting article! But this case does not apply. Please see the query example with no exception (ServerProfile + AutoTransactionOpenMode). It is very important for us that we can offer a trial version with the smallest possible installer. The retail version will then work with various 'real' SQL Servers - depends on requirement. Sorry Dmitri, under 'Behavior' I forgot to mention that all the examples use concurrent read access in separate sessions. By the way what can I do that the examples look better? The use of <pre><code> </code></pre> does not really help. Hello TeaMan, I might be wrong, but the main idea from the article was that any subsequent command after the lockexception is thrown will lead to error.
I think this can be easily validated and the third example proves the idea: just try running any single query in the first example in a separate transaction. Alternatively, you may try SQLite As for the code formatting, you left 4 spaces before each line of code and the site will format that part as a code. Hallo Dmitri, it has nothing to do with fragmented data or long running queries! 1.) There is a small test database with only 511 records in entity TestA und 8191 records in entity TestB. Hallo Dmitri, according to some studies I've now discovered why the error is not noticed before. |
Hello Dmitri, many thanks for the patch! It seems there is a weird workaround to suppress the wrong exception. After entity inserts, a simple read access to the table in auto-commit mode avoids the unwanted locking errors permanently until next inserts. For those interested here is an example: using( var connection = new SqlCeConnection( String.Format( "DataSource='{0}'", domain.Configuration.ConnectionInfo.ConnectionUrl.Resource ) ) ) { connection.Open(); var Command = connection.CreateCommand(); const string CommandText = "SELECT COUNT(*) FROM [{0}]"; foreach( var entity in domain.Model.Types.Entities ) { Command.CommandText = String.Format( CommandText, entity.MappingName ); Command.ExecuteScalar(); } } |