I've been using NHibernate 0.9.1 since its release. I skipped version 1.0.0 because of a few bugs it introduced, at least one of which has been fixed in 1.0.1, which is great. Thanks guys.

However, a bug that seems to have been introduced in 1.0.0 has apparently made it through to 1.0.1, but I don't understand it well enough to file a JIRA issue about it, IMO. Can someone please look at this exception stack trace and tell me what you make of it, please? It looks like Castle.DynamicProxy is emitting an assembly at runtime and getting it wrong. It's an intermittent bug, unfortunately. But it does seem to happen more when the web app is just started.

Exception Type System.ArgumentException
Message Duplicate type name within an assembly.
Source mscorlib
TargetSite Void CheckTypeNameConflict(System.String, System.Reflection.Emit.TypeBuilder)
StackTrace at System.Reflection.Emit.AssemblyBuilderData.CheckTypeNameConflict(String strTypeName, TypeBuilder enclosingType)
at System.Reflection.Emit.TypeBuilder.Init(String fullname, TypeAttributes attr, Type parent, Type[] interfaces, Module module, PackingSize iPackingSize, Int32 iTypeSize, TypeBuilder enclosingType)
at System.Reflection.Emit.ModuleBuilder.DefineTypeNoLock(String name, TypeAttributes attr, Type parent, Type[] interfaces)
at System.Reflection.Emit.ModuleBuilder.DefineType(String name, TypeAttributes attr, Type parent, Type[] interfaces)
at Castle.DynamicProxy.Builder.CodeGenerators.BaseCodeGenerator.CreateTypeBuilder(String typeName, Type baseType, Type[] inte


Exception Type NHibernate.HibernateException
Message Creating a proxy instance failed
Source NHibernate
TargetSite NHibernate.Proxy.INHibernateProxy GetProxy(System.Object, NHibernate.Engine.ISessionImplementor)
StackTrace at NHibernate.Proxy.CastleProxyFactory.GetProxy(Object id, ISessionImplementor session)
at NHibernate.Persister.AbstractEntityPersister.CreateProxy(Object id, ISessionImplementor session)
at NHibernate.Impl.SessionImpl.DoLoadByClass(Type clazz, Object id, Boolean checkDeleted, Boolean allowProxyCreation)
at NHibernate.Impl.SessionImpl.InternalLoad(Type clazz, Object id)
at NHibernate.Type.ManyToOneType.ResolveIdentifier(Object id, ISessionImplementor session)
at NHibernate.Type.EntityType.ResolveIdentifier(Object id, ISessionImplementor session, Object owner)
at NHibernate.Impl.SessionImpl.InitializeEntity(Object obj)
at NHibernate.Loader.Loader.Initia meters&n bsp;queryParameters)
at NHibernate.Impl.SessionImpl.Find(String query, QueryParameters parameters)[/i]

Looks like some race condition in DynamicProxy, but there are locks around that code. Could it be your accidentally creating multiple session factories during startup?

I don't think I am. The code I'm using to create the factory is as follows, which you can see I've put some locks in myself, and I'm using a static variable. But if you see something wrong, certainly let me know.



How does that look? Or any other ideas?

Thanks.

You can read a topic about the lock issue here: ASP.NET Serious memory leak.

This is double-checked locking, and it's known that it does not work in Java with some compilers and JVMs. Reportedly, it's also broken in .NET, see here: http://www.jirifabian.net/wordpress/index.php?p=43. So can you try using just single locking? Please tell us here if this solves the problem or not.

Thanks for the help.

I've applied the suggestions in the two links above this message by eliminating the double-locking and replacing it with the IHttpModule model as demonstrated in the conversation linked to previously. The problem hasn't resurfaced ever since.

Good to hear, these bugs are often tough to catch.

I have been getting this same error intermittently for quite some time now. I was originally thinking that it was an NHibernate issue that would hopefully get fixed in a new version so I never looked to deeply into it, but now I have come across this thread and see that it appears to be a threading problem.

I have been using the double check locking to create a session factory because I thought it was what Microsoft recommended. The following article lists the check as a solution

http://msdn.microsoft.com/library/defau ... elines.asp

Also, the new asp.net 2.0 providers use double check locking when they are initialized.

The report in this blog post, http://www.jirifabian.net/wordpress/index.php?p=43, that double check locking doesn’t work in .Net seems to be quite contradictory to what Microsoft says. Is there any other backing support to this claim?

Since the SessionFactory is used all the time to create sessions, I don’t think a single lock is the way to go since it will seriously hamper performance.

Sergey, are you sure this exception is caused by creating multiple session factories?

Are there any other workarounds for thread safe session factory creation?

I can't say anything about what is the cause because I haven't encountered it personally. For more information about double checked locking and .NET just try a Google search.

I read somewhere that another way to make singleton initialization thread-safe is to use a static readonly variable. Its initialization will then be guaranteed to be thread-safe by the runtime, and the initialization won't happen until the variable (actually the class it is defined in) is actually used.

Microsoft recommends this:

// .NET Singleton
sealed class Singleton
{
private Singleton() {}
public static readonly Singleton Instance = new Singleton();
}

see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/singletondespatt.asp

Dave, thats a nice reccomendation but you can't always set a variable that way. For example if data needs to be initialized from a configuration file or from another source you need to wait to get the data before you can initialize. This is exactly why the .net 2.0 provider model can not initialize in the way you have suiggested.

I am not totally convinced that this is a threading issue anyhow. I've set up some logging and Im just waiting for the error to occur again. I'll post my results as soon as the error happens again.

I take that back. I haven't significantly changed the code lately, but in the last couple weeks the problem has crashed the site (momentarily) several times.

I doubt the problem (for me) is a race condition with the factory, but just in case, here is the code I'm using for initializing the factory, in a class called DbMgr.

I'm seeing the "Message Duplicate type name within an assembly. " in 1.0.2 - it's definitely after my SessionFactory has finished setting up and seems to happen when the session factory is creating sessions and delegating them to mutliple child threads where they all begin loading objects at roughly the same time.

This only seems to happen for the first few sessions that start loading and after a batch of these exceptions all subsequent threads don't experience the problem.

Does anyone have any further thoughts on this? It seems to be a high concurrency environment problem.

Symon.

We're getting this exception too. It seems to be happening when an AppDomain gets recycled in IIS(ASP.Net). In this case all static state is reset.
If two users then subsequently hit the site at about the same time and both cause a castleproxy of the same class to be created to error occurs.

It seems to be the System.Reflection.Emit.TypeBuilder.Init that causes it. To fix this problem I think NH needs to serialize access to the proxy creation, perhaps in NHibernate.Proxy.CastleProxyFactory.GetProxy().

I think Sergey mentioned that NH already does locks around these calls but I couldn't find that anywhere in the source?

/Chris

DynamicProxy locks around the relevant code, NHibernate doesn't do it in the latest version. I'm bookmarking this thread to investigate the problems further later.