当我们尝试使用ASP.net MVC4网站更新用户时,我们收到此错误.请帮我看看.这在以前没有任何问题.
ErrorCode
:被引用的对象未被任何客户端锁定.
描述:执行当前Web请求期间发生未处理的异常.请查看堆栈跟踪以获取有关错误及其源自代码的位置的更多信息.
异常详细信息:Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode
所引用的对象未被任何客户端锁定.
来源错误:
在执行当前Web请求期间生成了未处理的异常.可以使用下面的异常堆栈跟踪来识别有关异常的起源和位置的信息.
堆栈跟踪:
[DataCacheException: ErrorCode:SubStatus :Object being referred to is not locked by any client.] Microsoft.ApplicationServer.Caching.DataCache.ThrowException(ErrStatus errStatus, Guid trackingId, Exception responseException, Byte[][] payload, EndpointID destination) +551 Microsoft.ApplicationServer.Caching.SocketClientProtocol.ExecuteApi(IVelocityRequestPacket request, IMonitoringListener listener) +287 Microsoft.ApplicationServer.Caching.SocketClientProtocol.PutAndUnlock(String key, Object value, DataCacheLockHandle lockHandle, TimeSpan timeout, DataCacheTag[] tags, String region, IMonitoringListener listener) +360 Microsoft.ApplicationServer.Caching.DataCache.InternalPutAndUnlock(String key, Object value, DataCacheLockHandle lockHandle, TimeSpan timeout, DataCacheTag[] tags, String region, IMonitoringListener listener) +216 Microsoft.ApplicationServer.Caching.<>c__DisplayClass9d. b__9c() +160 Microsoft.ApplicationServer.Caching.DataCache.PutAndUnlock(String key, Object value, DataCacheLockHandle lockHandle, TimeSpan timeout) +276 Microsoft.Web.DistributedCache.<>c__DisplayClass1c. b__1b() +52 Microsoft.Web.DistributedCache.<>c__DisplayClass31`1. b__30() +19 Microsoft.Web.DistributedCache.DataCacheRetryWrapper.PerformCacheOperation(Action action) +208 Microsoft.Web.DistributedCache.DataCacheForwarderBase.PerformCacheOperation(Func`1 func) +167 Microsoft.Web.DistributedCache.DataCacheForwarderBase.PutAndUnlock(String key, Object value, DataCacheLockHandle lockHandle, TimeSpan timeout) +162 System.Web.SessionState.SessionStateModule.OnReleaseState(Object source, EventArgs eventArgs) +929 System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +270
Gaurav Mantr.. 6
请检查您的请求是否超时.我们在项目中也遇到了完全相同的问题,我们发现这篇博文非常有助于找到我们遇到这个问题的原因:http://www.anujvarma.com/session-storage-app-fabric-cache/.
我们最初做的一件事是在web.config中将请求超时增加到5分钟(300秒),如博客文章中所述.但是我们只针对我们知道会遇到超时问题的操作.要更改所有操作的超时,您可以执行以下内容,如帖子中所述:
或者您可以做的是增加特定操作的超时:
恕我直言,第二个选项比第一个选项更可取,因为您的目标是特定操作,而不是整个网站.
但是,正如我在评论中所提到的,这并非万无一失.更好的替代方案是首先优化代码,以便您的请求不会花费很长时间.在我们的例子中,我们对存储操作有一个糟糕的重试策略,我们通过修改该重试策略来修复该问题.
请检查您的请求是否超时.我们在项目中也遇到了完全相同的问题,我们发现这篇博文非常有助于找到我们遇到这个问题的原因:http://www.anujvarma.com/session-storage-app-fabric-cache/.
我们最初做的一件事是在web.config中将请求超时增加到5分钟(300秒),如博客文章中所述.但是我们只针对我们知道会遇到超时问题的操作.要更改所有操作的超时,您可以执行以下内容,如帖子中所述:
<system.web> <httpRuntime executionTimeout = "300"/> </system.web>
或者您可以做的是增加特定操作的超时:
<location path="Controller/Action"> <system.web> <httpRuntime executionTimeout="300"/> </system.web> </location>
恕我直言,第二个选项比第一个选项更可取,因为您的目标是特定操作,而不是整个网站.
但是,正如我在评论中所提到的,这并非万无一失.更好的替代方案是首先优化代码,以便您的请求不会花费很长时间.在我们的例子中,我们对存储操作有一个糟糕的重试策略,我们通过修改该重试策略来修复该问题.