We're getting incorrect syntax errors (in anohter post, no responses) and we've found the cause.




We found it while troubleshooting this issue all day. Looks like this counter is injected into the alias but never decremented or reset. Doesn't rollover either...

We initialized the number at 1016789 which is when we get the error. We can now reproduce it.

We need to fix this problem asap since it's affecting our production server. I'm guessing it's the quantity of users*objects we use.

The number keeps getting higher idefinitly. I was thinking of adding something like:



But I have no idea what that will cause. I'm assuming many objects are cached and have their "uniqueInteger" with them. I also don't know what the upper bound is. I can see that the max alias is 10, +2 for an added suffix and it seems when this number is big enough (possibly too long) that the alias get's inappropriatly truncated.

I'll be happy to submit and issue, just looking for some advice for the short term.

Appears to be one of these lines:

NHibernate.Persister.NormalizedEntityPersister

Line: 1120



Line: 1184


The number will continue to grow until the AppDomain reloads. In are case we have about two days before our production goes down.

This number counts tables that NHibernate knows about. Do you really have more than one million tables, with new tables added every day? If not, it looks to me that you are somehow misusing NHibernate... Check that you are not building a new ISessionFactory per each request.

Hmm, I didn't see anywhere where NHibernate was statically storing tables mapping to this number.

When running the code it appeared to be a fairly independent number incrementing indefinitly and the Table class appears to be called for every table in every query from every user and each independently assigned a new number.

After hearing what you've stated, I'll look into this. We'll run under the assumption there should be only one number per Table in our database.


We close the factory after opening the session, could that be it? One of our developers found a memory leak that was fixed by closing it.

Not sure I understand ISessionFactory be static as well or does it do some cleanup that we're not allowing to happen by closing it?

Closing the session factory after you close the session means you will have to open a new session factory for the next session. Besides causing these overflows, this is also going to take a lot of time.

There indeed is a known problem with sessionfactory leaking memory in 1.0.2, if you use custom-constructed queries instead of using parameters (JIRA NH-559 and NH-604). If you are really hitting that problem, I would advise you to re-create the session factory once per some time, though this will only offset the problem, not make it go away. To avoid the memory leaks, you should change the application to use parameters instead of building HQL dynamically.

Thanks for your help Sergey. Because we have to support multiple connections we're thinking of initializing the SessionFactorys up front then storing them statically.

I ran accross the performance issues you indicated when I ran ANTS on it. Now that we understand how it's working I think we can employ our fix.

Thanks Again,
David