I have ASP.NET MVC app and WCF Service. Here is my code in MVC: client.Calculate() calls method Calculate inside service, and the service is hosted in Windows Application, so we have two separated domains. client.Calculate() calls this method:
It all works. But if we uncomment 1) or 2) in first code block - we got exception on 4) in second code block. There are two different domains and application contexts, because first method invoked by MVC, second - by WinApp. First code block runs inside transaction and opened session (Xtensive.Practices.Web.SessionManager). That exception throws even if we put 3) instead of above line. So we have some table lock, maybe. Any ideas? |
The answer is copied from the comments to original question. Seems it is expected timeout. You are changing filter instance within one transaction and trying to read the same instance within another one. So attempt to read locked instance is timing out as it must be. As an option you can try to switch isolation level to Snapshot or ReadCommitted+Snapshot. Or try not to change filter. Additionally if you need to access changed filter in context of |
Which transaction isolation level you use? Is it repeatable read? The case looks like a table lock.
We use Xtensive.Practices.Web.SessionManager for ASP.NET MVC.
But only in this case we got problem, so I don't know, which isolation level is used by SessionManager :)
What FilterRepository.GetById(id) does? It is called from both places.
BTW, could you send a sample or a real app so we could debug the issue instead of guessing? This could drastically shorten the time required for issue resolving.
Sorry, but app is commercial, so I can't share it's sources.
GetById - it's something like this:
And doesn't matter, what we do in Service() - making another query except filterRepository.GetById(idFilter), 1) or 2), leads to exception in 4)
OK, I see. Then let's try solving the issue in the Q/A mode. Could you grab the output of SQL Profiler so we could analyze what queries are being executed on the server? Thanks.
Seems it is expected timeout. You are changing filter instance within one transaction and trying to read the same instance within another one. So attempt to read locked instance is timing out as it must be. As an option you can try to switch isolation level to Snapshot or ReadCommitted+Snapshot. Or try not to change filter.
Additionally if you need to access changed filter in context of Calculate method you in a trouble because you need to commit to make changes visible but
SessionManager
controls transaction by its own. In this case filter settings may be sent asCalculate
method parametersOk, I understand.
We forgot, that SessionManager opens transaction, so we were surprised by such behavior.
Thanks.
Hi Ness
Can we consider my comments as an answer?
If so I'd copy the text as reply to make you able to accept it and close question.
Btw, did you find an approach to avoid locking?
Yes, Alex.
We found approach - we moved method to service, so MVC method doesn't use database.