Hello --

LLBLGen Designer: 2.5 Final, Sept. 24, 2007 release Runtime: SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll: version 2.5.7.924 Project Info: Adapter (General2005 Preset), C#, .Net 2.0, SQL Server 2005

I was running some load tests against a Windows 2003 server and was wondering if you all could shed some light on the execption below:

Exception type: ORMLockTimeoutException 
Exception message: Timeout waiting for lock 

Stack Trace:

SD.LLBLGen.Pro.ORMSupportClasses.TimedLock.Lock(Object o, TimeSpan timeout)
   at SD.LLBLGen.Pro.ORMSupportClasses.TimedLock.Lock(Object o)
   at SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoStorage.GetInstancesToInject(Type targetType)
   at SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProvider.GetInstancesToInject(Type targetType)
   at SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProviderSingleton.PerformDependencyInjection(Object injectionTarget)
   at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.PerformDependencyInjection()
   at DataEntities.EntityClasses.CustomerEntity.InitClassMembers()
   at DataEntities.EntityClasses.CustomerEntity.InitClassEmpty(IValidator validator, IEntityFields2 fields)
   at DataEntities.EntityClasses.CustomerEntity..ctor(Int32 customerId)

The server's CPU was at 100%, and I did notice a couple of other peculiar exceptions in the event log that were not in LLBLGen code.

I thought the "lock time out" might have been due to waiting for a SQL Server lock, but looking at the stack trace, that doesn't seem possible. (No call to the database should have been made in that stack trace.)

Also, we did not write any code that uses dependency injection.

Is this "just" the result of a server that is overloaded?

Thanks, -Ryan Casey

Hi Ryan,

This error is a timeout exception for TimeOut locks used inside the code.This indeed is related to singleton dependency injection. I see that it rises on CustomerEntity constructor. Are you sure you aren't using dependency injection?

Could you please provide the code snippet where you instantiate the customerEntity? Also, could you please post your *.config file?

daelmo wrote:

Hi Ryan,

This error is a timeout exception for TimeOut locks used inside the code.This indeed is related to singleton dependency injection. I see that it rises on CustomerEntity constructor. Are you sure you aren't using dependency injection?

Yes, I'm sure we are not using dependency injection. I don't know if LLBLGen uses it by default, but we have not written any code that uses it nor adding any thing to the web.config file to enable it.

Also, the "CustomerEntity" CTor is one generated by LLBLGen, it is not a custom CTor.

daelmo wrote:

Could you please provide the code snippet where you instantiate the customerEntity? Also, could you please post your *.config file?

Sure. The code is pretty simple. It's basically a web service method that is being called:

[WebMethod]
public void Submit(int testQuestionId, int testAnswerId)
{
    try
    {
        System.Diagnostics.Trace.WriteLine("***********************");

        System.Diagnostics.Trace.WriteLine(string.Format("Submit fired. TestQ:{0} TestA:{1}", testQuestionId, testAnswerId));

        CustomerEntity customerEntity = new CustomerEntity(this.userInfo.customerId);
        // ... rest of code...Exception occurs on the line above this.

Web.config portions that are LLBLGen Specific:

  <sqlServerCatalogNameOverwrites>
    <add key="db_development" value=""/>
  </sqlServerCatalogNameOverwrites>
  <appSettings>

  <!-- LLBLGen Specific Settings -->
    <add key="Main.ConnectionString" value="data source=foo;initial catalog=db_development;User ID=db_user;Password=*****;persist security info=False;packet size=4096"/>
    <add key="SqlServerDQECompatibilityLevel" value="2"/>
    <!-- End LLBLGen -->
  </appSettings>
    
      <system.diagnostics>
    <switches>
      <!-- Trace messages for LLBL Gen, the datalayer -->
      <add name="SqlServerDQE" value="4"/>
      <add name="ORMGeneral" value="0"/>
      <add name="ORMStateManagement" value="0"/>
      <add name="ORMPersistenceExecution" value="0"/>
    </switches>
  </system.diagnostics>

Thanks, -Ryan Casey

caseyry wrote:

daelmo wrote:

Hi Ryan,

This error is a timeout exception for TimeOut locks used inside the code.This indeed is related to singleton dependency injection. I see that it rises on CustomerEntity constructor. Are you sure you aren't using dependency injection?

Yes, I'm sure we are not using dependency injection. I don't know if LLBLGen uses it by default, but we have not written any code that uses it nor adding any thing to the web.config file to enable it.

The code goes through the same routine to check if there are injectables for the entity just instantiated. It opens a timed lock on the storage for types and instances, then checks if there are injectables defined and if not, releases the lock again.

Inside the o/r core a cache is build with type-injectioninfo combinations. This is required so lookups are very fast after that. For example an entity can implement various interfaces and can be of different types (subtypes etc.). To be able to quickly find if a type has any injectables to inject, the cache is build along the way. So if you first use a CustomerEntity, it will add CustomerEntity and the injectioninfo objects for that type to the cache. Any other usage of CustomerEntity will use that cached info. If no DI is used, the type has 'null' as injectioninfo and it is a single lock operation: a lock is requested on the cache, the value is read, the lock is released. When the type ISN'T present, the injectioninfo's are created, a lock is requested, the infos are added, the lock is released.

The lock used is a TimedLock, which has a timer so it won't wait forever causing a deadlock. When it can't obtain a lock in the given time set (default is 10 seconds), it will throw the ORMLockTimeoutException. In general you shouldn't see this.

The cache is build up at runtime and not at startup time, because it could cause a delay if it's been build up at startup time, which might be unacceptable.

You were saying you had different exceptions as well. Which were they exactly? THe lock causing the timeout is used as a call from the entity CTor as there the DI code is called.

Otis wrote:

You were saying you had different exceptions as well. Which were they exactly? THe lock causing the timeout is used as a call from the entity CTor as there the DI code is called.

The exception was: Exception information: Exception type: TargetInvocationException Exception message: Exception has been thrown by the target of an invocation.

    Stack trace:    
    at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck)
   at System.Activator.CreateInstance[T]()
   at BizServer.GenericBizEntity`1..ctor(T genericEntity)
   at UI.TestSection.RecordSectionExit()
   at UI.TestSection.ImageButtonExitSection_Click(Object sender, ImageClickEventArgs e)
   at System.Web.UI.WebControls.ImageButton.OnClick(ImageClickEventArgs e)
   at System.Web.UI.WebControls.ImageButton.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.WebControls.ImageButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

The exception is throw when creating one of our generic "business" objects. I tried searching for similar problems, but couldn't find any that didn't seem to be related to controls or other UI issues.

Again, the web server CPU was at 100%, which I'm sure had something to do with the exceptions. However, obviously it would be nice not to have run time exceptions generated.

Thanks, -Ryan Casey

caseyry wrote:

Otis wrote:

You were saying you had different exceptions as well. Which were they exactly? THe lock causing the timeout is used as a call from the entity CTor as there the DI code is called.

The exception was: Exception information: Exception type: TargetInvocationException Exception message: Exception has been thrown by the target of an invocation.

    Stack trace:    
    at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck)
   at System.Activator.CreateInstance[T]()
   at BizServer.GenericBizEntity`1..ctor(T genericEntity)
   at UI.TestSection.RecordSectionExit()
   at UI.TestSection.ImageButtonExitSection_Click(Object sender, ImageClickEventArgs e)
   at System.Web.UI.WebControls.ImageButton.OnClick(ImageClickEventArgs e)
   at System.Web.UI.WebControls.ImageButton.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.WebControls.ImageButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

The exception is throw when creating one of our generic "business" objects. I tried searching for similar problems, but couldn't find any that didn't seem to be related to controls or other UI issues.

I don't think it's related.

Again, the web server CPU was at 100%, which I'm sure had something to do with the exceptions. However, obviously it would be nice not to have run time exceptions generated.

True, however it can be a thread was 'starved' so it couldn't get a lock and timed out. THe timeout is generated by .NET btw, the code tries via Monitor.TryEnter by specifiying a timespan if it can get a hold on the object. So if .NET detected it couldn't get a hold on the object for 10 seconds, it returns and the exception is thrown.

In v2.6 we'll add an optimization to the runtime which will bypass the locks if no DI is used, however we've to check if we internally don't want to use DI (as some classes were a good candidate). We haven't heard any reports about this exception, so I guess it's the stress the app was under which didn't allow a lock to be released in the time set.

Otis wrote:

In v2.6 we'll add an optimization to the runtime which will bypass the locks if no DI is used, however we've to check if we internally don't want to use DI (as some classes were a good candidate). We haven't heard any reports about this exception, so I guess it's the stress the app was under which didn't allow a lock to be released in the time set.

That would be helpful. If I'm able to replicate this easily, I'll send you all additional info, otherwise I look forward to 2.6.

Thanks.

Ok. I'll close this thread for now. If you have any additional info to reproduce this, just post a new message in this thread and it will be re-opened automatically and be added to our support queues automatically.