Hi there, We’ve been running into the issue of crashing authentication method where it tries to update some fields in multiple database tables. We haven’t been able to find out the exact cause of this issue but we are getting an exception under UnitOfWork2. Currently, we are using LLBLGen Pro Version 5.4.2. Here is an exception details:

Object reference not set to an instance of an object. - at SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWork2.ConstructSaveProcessQueues() at SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWork2.PerformPreCommitActions(IDataAccessAdapter adapterToUse, Boolean autoCommit) at SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWork2.CommitImpl(IDataAccessAdapter adapterToUse, Boolean autoCommit) at DCSE.DataAccess.LLBLGen.EntityDataCore.CommitUnitOfWork(UnitOfWorkStatementOrder statementOrder, Boolean alwaysRollback)

If you could help us giving some more details why it would throw this error, or help us create additional logging that may identify the cause? Let me give you some more explanation about this production issue. Our online application works for weeks at a stretch without issue, until something happens and it starts throwing this error on every attempted login, and continues throwing this error until we restart our service’s “app pool” from Windows IIS manager. This has happened about ten times over the past five months. We have not been able to replicate this issue in our Test environment, although the volume of usage is much lower. Let me know if you need any other information.

The stacktrace you're posting isn't the complete stacktrace I think. Nevertheless, the exception occurs when the system tries to topologically sort the graph of the entities to persist, (which is the ordering of which entity to persist first). As you say it's not a deterministic situation (you can't repro it in testing), it's likely caused by an outside factor, e.g. multi-threading/reusing of elements instead of recreating of elements.

However admitted, multi-threading related issues occur more frequently than once in a 3 month period. So just in case, make sure you're not re-using an Uow instance, always create a new one. Also if this exception occurs, please check whether memory is limited or not, i.e. whether you run into memory issues and there's a memory leak somewhere (caching entities in memory which keep other entities in memory unintentionally). I'm leaning towards this as it takes such a long time to occur.

Attached you'll find debug builds of the ORMSupportClasses dll. It comes with the pdb file and it's key you place the right ormsupportclasses dll and pdb file in your application's folder. As they're signed, it should be a drop-in replacement for you. This should give more insight in on which line the exception occurs so we can track back from there what might have happened.

Thank you for your response.

I have tried replacing the DLL you have provided, but I am getting an exception. I have attached here Method definition and Exception details to give you more clear idea. We are using both DB2 and SQL Server databases to pull information. So that's the reason we are using "SD.LLBLGen.Pro.DQE.DataDirectDB2.dll" and "SD.LLBLGen.Pro.DQE.SqlServer.dll". I couldn't able to figure out the issue because both "SD.LLBLGen.Pro.ORMSupportClasses.dll" is having same version. (Means the one we are using and the one you send me to give us more insight of trace logs.)

Let me know if you need anything from me.

Hmm. You're sure you're using 5.4.2? The db2 specific DQE which is custom (We don't support datadirect, only IBM's own db2 connector), does it derive from our code? It looks like it doesn't derive from our base class?

Yes, I am using same version 5.4.2. I have attached a screenshot of the current version. I know it will be difficult for you to understand the issue but I am trying my best to explain you.

I am getting an error message in the Data Access Adapter class (auto generated by LLBLGEN Pro 5.4) which controls the complete database interaction with the database for all objects. In my case, I am using it for DB2 database.

Following is the Declaration in the Extension class "DataAccessAdapter" which is inherited from "SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase" class

protected override DynamicQueryEngineBase CreateDynamicQueryEngine() { return this.PostProcessNewDynamicQueryEngine(new SD.LLBLGen.Pro.DQE.DB2.DynamicQueryEngine()); }

inside this method, I am getting the exception. The method PostProcessNewDynamicQueryEngine(DynamicQueryEngineBase toProcess) is declared in abstract class SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.

And yes,db2 specific DQE has a class named DynamicQueryEngine which is inherited from SD.LLBLGen.Pro.ORMSupportClasses.DynamicQueryEngineBase.

I hope this helps. Let me know if you need any other information.

Could you compile the DB2 DQE project that's using datadirect with the ORMSupportClasses dll I attached (as that's not our source)? The thing is, I used the exact same sourcecode that's used for the original ormsupportclasses dll and everything should be the same so that method should work fine as at runtime there's just 1 ORMSupportClasses dll in memory. So the method you get the exception on shouldn't fail as the DQE class derives from the proper class.

Also, I included 2 versions: the netstandard 2.0 one and the net full one. You have to use the .net full one.

yes, I am using net full version(net452). I don't have DB2 DQE project to compile because I only have DLL file for that and I have added that as a reference.

Same kind of error I am getting for "SD.LLBLGen.Pro.DQE.SqlServer.dll"(I think it's your source) as well. I have attached a snapshot of an error message. Just for your reference, here is a code from my Extension method. (I have updated ORMSupportClasses reference in this project.)

public class GlimpseDynamicQueryEngine : DynamicQueryEngine { protected override DbCommand CreateCommand(DbConnection connectionToUse) { var cmd = base.CreateCommand(connectionToUse);

        var wrappedCommand = new Glimpse.Ado.AlternateType.GlimpseDbCommand(cmd);

        return cmd;
    }
}

Compilation Error: The type 'DynamicQueryEngineBase' is defined in an assembly that is not referenced. You must add a reference to assembly 'SD.LLBLGen.Pro.ORMSupportClasses, Version=5.4.0.0, Culture=neutral, PublicKeyToken=null'.

Could you able to recognize the issue why I couldn't able to replace the ORMSupportClasses DLL? Do you think it will be helpful to share my ORMSupportClasses DLL with you? If yes, then please provide me any other secure way to share that DLL with you.

Please download the source code of the SQLDQE from LLBLGen Pro website. Login by your customer ID and go "My Account" then click on the LLBLGen version you are using, and under "Extras" you should find the source code.

You need to re-compile it with the debug version of the OrmSupportClasses dll that was given to you.

Hello,

As per your suggestion, I have downloaded source code for both SQL DQE and DB2 DQE and tried to replace a DLL you provide me initially (to capture exception inside LLBLGEN) but I am not be able to replace it easily as there are some references throwing an error. But, here I am providing you my code in which I am performing CommitUnitOfWork(). Can you please check and see if you find any problems in what I am doing? This code works just fine, but sometimes once in a week or in two weeks website goes down because this specific CommitUnitOfWork() throws an errors while users try to Login. The interesting thing here is, while this issue occurs, users can still be able to register for new account. That is also using CommitUnitOfWork() process. So in short, Login's piece of code fails while Registration's piece of code works fine. Do you think there might be any memory issue because lot of transactions happening to database tables associated with Login process?

Please find attached full details of exception and code for CommitUnitOfWork() to review.

I appriciate your help.

You're merging a set of Unit of work instances into another unit of work, but after commit? I don't see the purpose for the

this.InsertQueue.AddRange(uow.GetInsertQueue()); this.UpdateQueue.AddRange(uow.GetUpdateQueue());

lines.

The problem is that this copies objects from the queues, but when you commit the same UoW object again (I think you cache these? don't do that, never cache these objects, nor adapter, they're very lightweight, no need for caching) it creates new queues and therefore removes references to the old objects but as you copied them, they're still in memory!

So: - don't cache adapters, unit of works etc. to avoid recreating them, they're lightweight and designed to be recreated every time. - don't keep objects around like you do: the copy actions like the ones above keep objects in memory and the entities too. They might be attached to some object that ends up in the queue in a next uow commit, so all entities will be reexamined when the queues have to be calculated as it traverses the graph again (as they're all reachable). - you can pass around a unit of work object: it doesn't know how to persist itself, that's by design. So instead of creating multiple unit of works and store them in a list, you can use 1 unit of work and pass that to methods that collect work: make these add their work to that unit of work, and simply commit that at the end.

As the error isn't deterministic, and occurs rarely, I think it's indeed a memory problem (not 'out of memory' but close, so you see all kind of weird things fail. It might be due to the copying of the data in the lines above (remove these at least). It's perhaps wise to monitor memory consumption over a week or 2 to see if you have a memory problem.

Otis, Thank you so much for your quick response. We're having this code since so long so we haven't paid attention to it. But, I will remove those 2 lines of code and will check if that fixes my issue.

We've created CommitUnitOfWork method to reuse the code across multiple applications. Do you think I should make any other changes to CommitUnitOfWork method I shared in previous post?

Thank you again!

I think removing those two lines which copy the data over is a good first step. Also check if you indeed don't keep Unit of work objects around after CommitUnitOfWork has been called. You should get rid of them when things have been committed.