Hi,

Does LLBLGen when Querying the database by using QuerySpec and projection have any kind of cache?

On one place (let's call it A), we have code like this

           var qf = new QueryFactory();
                var query = qf.Create()
                    .Select(() => new Model A
                    { 

mapping for Model A from VIEW X ... xFields.A , xFields.B, xFields.C ...  

SubModel = new SubmodelA  {
 Z = entityFields.Z.ToValue ...
}

Quite simple.

In 2nd place (let's call it B), we have very similar code (similar end-result-model)

           var qf = new QueryFactory();
                var query = qf.Create()
                    .Select(() => new Model A
                    { 

mapping... from TABLE Y .. yFields.A , yFields.B, yFields.C ...  
WITHOUT SubModel
....

So, their common point is the creation of the same type of model (A). Sorry, I cannot provide the exact code due to NDA, but I assure you that both pieces are straightforward, as presented above.

Our code is (rarely) throwing SQL exceptions on Code B, for property Z, which isn't used on that place at all and is "used" from a different view.

After restarting the IIS/application, everything works as expected, no further errors are thrown.

It seems like there is some sort of dynamic cache under the hood, which I can't figure out, fix, disable, or something.

I'm using LLBLGen 5.6.0 with PostgreSQL.

Can you assist me, with how to prevent this? Thanks.

No we don't use any form of query caching. All queries are created on the fly as-is. We do use a cache for projection lambdas, the compiled forms of these. We use a key generated from the projection lambda to determine which projection lambda to use. However this is related to the projection of the set coming from the database, so the query already would have executed ok. This isn't the case with your issue.

The fixes I could find which are perhaps related:

In 5.6.3 we fixed an issue in this region:

• Fix Runtime Libraries 5.6 5.6.3 25-Feb-2020 A race condition in an edge case could lead to a NRE in the lambda cache in QuerySpec

In 5.6.5 we fixed an issue in the string builder cache:

• Fix Runtime Libraries 5.6 5.6.5 16-Sep-2020 In an edge case, a race condition can occur in the StringBuilderCache where Release is executed on a different thread

Those fixes come to mind when I look at your scenario. You're using 5.6.0 so it might be good to check if the updated runtimes for 5.6 fix it.

Additionally, please make sure in your fetch code that the adapter you're using for fetching the set is always recreated and not shared among threads in a cached/static instance.

Hi Otis,

Thanks for looking into this - I'll give the upgrade a shot.

Ivan