LockNotGrantedException after any call to web service goes wrong

[Thomas]

Hi all

I'm using Telerik Data Access and using it to generate our plain WCF service. I actually really like how it generates the service.

However, everything goes wrong when an exception occurs. This could be a very simple exception, like an object not being found by it's DTO key or trying to add an object with the same value for a unique field as an existing one. When this happens, every CRUD operation that I'm trying to execute (on the client sent to the WCF service and so to the data access library and the database) gives me a LockNotGrantedException. This exception (the LockNotGrantedException) keeps being thrown for every operation (even valid ones), until I restart the WCF service (which is not supposed to happen).

Stack trace (sorry for the little bit of Dutch in there...):

Telerik.OpenAccess.Exceptions.LockNotGrantedException

Telerik.OpenAccess.RT.sql.SQLException: Lock request time out period exceeded. ---> System.Data.SqlClient.SqlException: Lock request time out period exceeded.
   bij System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   bij System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   bij System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   bij System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   bij System.Data.SqlClient.SqlDataReader.TryHasMoreRows(Boolean& moreRows)
   bij System.Data.SqlClient.SqlDataReader.TryReadInternal(Boolean setTimeout, Boolean& more)
   bij System.Data.SqlClient.SqlDataReader.Read()
   bij OpenAccessRuntime.Intellitrace.Read(DbDataReader reader, String id)
   bij Telerik.OpenAccess.Runtime.Logging.LoggingDbDataReader.Read()
   bij Telerik.OpenAccess.RT.Adonet2Generic.Impl.ResultSetImp.next()
   --- Einde van intern uitzonderingsstackpad ---
   bij Telerik.OpenAccess.RT.Adonet2Generic.Impl.ResultSetImp.next()
   bij OpenAccessRuntime.Relational.fetch.FetchResultImp.rsNext()
   bij OpenAccessRuntime.Relational.fetch.FetchResultImp.hasNext()

Next, I also noticed that the client application (a console application in this case) kept trying to execute the operation, even after the LockNotGrantedException was thrown in the service application. So I had to stop the client application to stop the calls to the WCF service. I don't know if that is something caused by the service and the LockNotGrantedException, or something specific to a console application?

I can also give you the following information. I tried to change the isolation level of the model and setting it to ReadUncommited still caused a LockNotGrantedException to be thrown when any operation occurs that throws an exception and still caused the console application to keep trying to execute the operation, but when shutting down the console application and restarting it, valid operations don't throw this LockNotGrantedException anymore.
As a side note: because in the docs it is stated that it is deprecated to change the isolation level on the model, I configured it like this:

protected override void Init(string connectionString, string cacheKey, BackendConfiguration backendConfiguration, MetadataContainer metadataContainer, Assembly callingAssembly)
{
    base.Init(connectionString, cacheKey, backendConfiguration, metadataContainer, callingAssembly);
    this.ContextOptions.IsolationLevel = IsolationLevel.ReadUncommitted;
}

What other information can I give you? Well, of course I extended the interface (I made it partial in the T4 templates) and the service. I also extended the assemblers to transform SqlGeography in WKT and so I also extended the DTO's to add this WKT to the relevant objects.
I also adapted the T4 templates for the assemblers a bit. I implemented the AssembleNavigational() and adapted it in a way that no StackOverflowException occurs. This way it is possible to get a DTO with its navigation properties. I also changed the T4 templates so a method was added that made the reverse also possible: filling navigation properties on the DTO's and so setting those in the entities. That way, it is also possible to execute CUD operations with the navigation properties on the DTO on the client. Of course, I did set 'IsManaged' to 'true'.

Can someone help me with this LockNotGrantedException?
Please ask when further information is required. However, this is quite important and urgent. ;)

Kind regards
Thomas

[Thomas]

Hi all

I just found a way to prevent the LockNotGrantedException from being thrown.

I noticed that, in the WCF service, the OpenAccessContext is never disposed, like e.g. posted here. I tried disposing the OpenAccessContext (inside the finally) in the method that I used to generated the error (from the client), and LockNotGrantedExceptions weren't thrown any longer. So the solution could be to dispose the OpenAccessContext in every WCF method.

However, I don't really know how I should implement this exactly, for several reasons.
- The instance of the OpenAccessContext used in the WCF service is of type IEntitiesModelUnitOfWork, that has no reference to IDisposable. So I should, every time I want to call Dispose(), cast the IEntitiesModelUnitOfWork to an IDisposable... It maybe could be an idea to change the type to just EntitiesModel?
- I'm also wondering if it is a good idea to dispose the context every time when the instance is only created a single time...

As a side note: the console application still keeps trying to do the same operation even after retrieving a FaultException from the service. However, I think that's console application specific (it only happens in debug mode).

Kind regards
Thomas

[Thomas]

Hi again

I've got another update.

I found a problem and the solution for that problem could have resolved this problem.
I mentioned in my first post that I used the assemblers to convert an SqlGeography in the entities to a WKT in the DTO's and vice versa. For that, I needed to add a reference to the dll Microsoft.SqlServer.Types in the WCF service project. What I then noticed, is that the dll added as reference in the Telerik Data Access library (by Telerik Data Access) has another version and another location than the one I added a reference to. (I used the one found in the 'Extensions' tab under 'Assemblies' in the 'Add Reference...' Visual Studio dialog.) To resolve this, I replaced the reference to the dll used in the Telerik Data Access class library (that had a reference to a dll in the GAC (C:\Windows\assembly)) with the one I added in the WCF service project (that had a reference to a dll in Program Files).
Was that a good thing to do? Or was it better to let the dll in the Telerik Data Access library be and change the one in the WCF service project?

Also, a few questions remain:
- Why didn't I get an InvalidCastException or something similar? And why did I always get a LockNotGrantedException?
- Isn't it a problem when the context used for the UnitOfWork never gets disposed?

Thank you for answering my questions.

Kind regards
Thomas

[Doroteya]

Hello Thomas,

Thank you for contacting us.

I took the time to go through the provided details, and regarding the specific reason for the error on your side, until now I was unable to understand what exactly might cause it. However, you have a point that the context should be disposed, and that in general locking can occur when the connections are not handled properly. Therefore, I would suggest to you to modify the generated plain service to manage its instance percall. The following list of resources will provide you with the necessary guidance:

- WCF Tutorial: Per-Call Service
- Discover Mighty Instance Management Techniques For Developing WCF Apps
- Understand How Per Call Service Instance mode works in WCF

I hope this helps. Do let us know if you need further information.


Regards,
Doroteya
Telerik

 

 

[Thomas]

Hi Doroteya

Thank you for answering. I appreciate that you took your time to give the best fitting answer possible.

However, the plain web service has already the InstanceContextMode set to PerCall by default by the Telerik templates, and I didn't change that.
Please note also that I will be unable to test any other solutions easily because in fact I solved the problem by changing the reference to Microsoft.SqlServer.Types to the same version in both projects. I'm at the moment just wondering why a LockNotGrantedException was thrown and whether the context used for the UnitOfWork shouldn't be disposed (or does it get disposed after the call, when InstanceContextMode is set to PerCall).

Kind regards
Thomas

[Viktor Zhivkov]

Hello Thomas,

Can you confirm that you have resolved the issue by changing version of referenced Microsoft.SqlServer.Types assembly? 

Regards,
Viktor Zhivkov
Telerik

 

 

[Thomas]

Hi Viktor

Indeed, when I changed the version of the referenced Microsoft.SqlServer.Types in the WCF project to the same version as the referenced Microsoft.SqlServer.Types in the Telerik Data Access class library, the application stopped throwing LockNotGrantedExceptions. But could you maybe explain me why LockNotGrantedExceptions were thrown?

Kind regards
Thomas

[Kristian Nikolov]

Hi Thomas,

We are glad you have resolved the situation on your side.

Regarding your question - it is likely that one of your projects, the one containing the model or the one containing the WCF service used version 11.0.0.0 of the Microsoft.SqlServer.Types assembly. Telerik Data Access supports version 10.0.0.0 of the assembly in question. Version 11.0.0.0 is not supported and the product is not tested against it. Therefore using version 11.0.0.0 of Microsoft.SqlsServer.Types can lead to unexpected behavior at runtime. If indeed one of your projects used version 11.0.0.0, the exception you have experienced could be a result of the combination of that incompatibility and the specific usage scenario.

I hope this helps. Should you have any more questions feel free to post at our forums again.

Regards,
Kristian Nikolov
Telerik

 

 

[Thomas]

Hi Kristian

Thank you for posting your answer. It was indeed the 11.0.0.0 version that caused the problems. It's just a bit a pity that it's so hard to find out that that was actually the cause...

Kind regards
Thomas

[Kristian Nikolov]

Hello Thomas,

Thank you for your feedback.

We recognize that the incompatibility with the Microsoft.SqlServer.Types 11.0.0.0 assembly is not visible enough for our users. As seemingly unrelated exceptions can occur when using this assembly we plan to introduce resources regarding the scenario in order to make troubleshooting easier.

I hope this helps. In case you have further questions, do post at our forums again.

Regards,
Kristian Nikolov
Telerik