I'm using NHibernate version 1.0.2 and I've discovered a bug with 2nd level caching when creating a session with an existing database connection. When using the following overload:



The txTimestamp is passed through as long.MinValue which then causes problems with inserting items into the cache.

The following will address this problem:



The creation of the timestamp was promoted to the private implementation and removed from the public overloads. Due to my limited understanding of NH internals, I need to know if this will cause any problems?

Was this ever addressed? We manage our own connections and have run into the same issue. This keeps us from being able to use caching at all. I don't know if a JIRA was ever created for it - if it's fixed in 1.2A1 or what.

I think we'll probably have to use a custom build and fix this as it's a killer for us.

Thx,

benster

This is not a bug. If you are managing your own connections, NHibernate disables the use of second-level cache for the session to be safe. You can implement your own connection provider to work around it.

Thx - I saw some traffic on the Developers list after posting this.

Unfortunately we can't do that because we are managing our own connections because of the need to use multiple connection strings depending on the type of session requested. There's no way through that interface to determine this. Currently we wrap NH completely and my session wrapper object knows its type and can request from our pooling an appropriate connection when it's connected.

benster