Unable to cast object of type 'NHibernate.Impl.ExpandedQueryExpression' to type 'NHibernate.Linq.NhLinqExpression' again

[Yohei Iwano]

I'm sorry for my poor English. But this happens in our system too.

At first, let me explain my understanding.
When I query linq contains collection parameter like this
from x in session.Query<SomeEntity> where
collectionParam.Contains(x.Col1) select x

It will process like this

1. Retrieve NhLinqExpression Query Plan from QueryPlanCache
2. Retrieve ExpandedQueryExpression Query Plan from QueryPlanCache

but if the collection parameter contains only one value(like "var
collectionParam = new int[] {100}").
It will process like this

1. Retrieve NhLinqExpression Query Plan from QueryPlanCache
2. Retrieve NhLinqExpression(not ExpandedQueryExpression!) Query Plan
from QueryPlanCache

this happens because of problem in creation of "query plan cache key".
When the collection parameter contains only one value,
NhLinqExpression and ExpandedQueryExpression both make same query plan
cache key.
(see ExpressionQueryImpl.ExpandParameters method)

Normally, this process works fine. But if the GC occurs between 1 and
2, and the NhLinqExpression objects are collected,
ExpandedQueryExpression(which is the same query plan cache key as
NhLinqExpression) is now going to cache.
In this time, softReferenceCache object in the SoftLimitMRUCache is
poisoned. And next time you try to execute linq, InvalidCastException
occurs...

I'm caching SessionFactory object in static field, and reuse it
between all threads/requests. The pollution of QueryPlanCache is
really serious problem...
(Additionally, I'm using ThreadStaticSessionContext to share Session
object between application layers. So I cannot recreate SessionFactory
object easily...)

Yohei

[Vikas Roonwal]

Hi,

Thanks for the update, but is this really a garbage collection related issue that needs to be fixed?
Can someone please provide a workaround for this (I do not mind if the workaround entails a bit of performance overhead).
We keep seeing this issue intermittently in our application and not being able to reproduce this at will makes it scarier.

Thanks,
~Vikas

--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

[Trinition]

I just started observing this in our system as usage is slowly ramping up.  There appears to be JIRA issue #NH-3050 ( https://nhibernate.jira.com/browse/NH-3050 ) for this, but it is as of yet unresolved.