hi, i have an application where i need that calling session.Get(id) will always retun the same object istance.
as solution i want to use the same session for all the application life, there are few/none concurrency use of it so i think to wrap it in a threadsafe class that will use a lock for every method call.

do you think that i can have problem with this solution?

Why do you have this requirement? Can you override Equals and GetHashCode on your objects instead?

Keeping the same ISession instance active (a bad idea anyway) won't guarantee that calling Get will always return the same instance of an object, that depends on the caching strategy employed. If you really want to do this, take a close look at NHibernate's second level caching.

hi kork2, I think the approach you are describing is referred to as "session per application" and its generally considered an antipattern. (It's acceptable if the session is a bit sorter, in which case its called 'extended session' or 'session-per-conversation'.) I was considering session-per-app a while ago but eventually abandoned the idea once I got to better understand NH's first-level caching and reattaching objects. In any case, below are the notes I kept. Let me know how it goes for you.

"What was originally 'long session' (reference docs prior to 3.2 and HiA) is now 'extended session' and 'session-per-conversation' (reference docs 3.2, JPwH)... Both books provide a much better description than any online material I've found.

To clarify in case anyone's interested:
Sparce description in the Reference Documentation:
http://www.hibernate.org/hib_docs/v3/re ... ongsession

Hibernate in Action: section 8.2.4

Java Persistence with Hibernate: section 11.2.3

Section in the wiki on the open session in view pattern:
http://www.hibernate.org/43.html#A5 "

[Source: http://forum.hibernate.org/viewtopic.ph ... 1&start=30 ]

I wouldn't normally call session.Get(id) multiple times for retreiving the same object. Even so, I think this would work since sessions define object identity scope. In my programming, however, I'd call it once then keep a reference to the object it returns. As long as you have the same session open, any changes made can be presisted back to the database by calling session.Flush(). If you open a new session then you can call session.Update(obj) which reattaches it.


As far as I understand, keeping the same session instance open will guarantee object identity (pls correct me if I'm wrong). And from what I've read about NH's second-level caching (never used it myself), objects are stored by value, so this wouldn't fit kork2's requirement.

i try to explain better what i need, my bigger problem are events,
for example think to a MyEntity wich will throw a notifed event when somebody call a Notify() method on it.

i have objects that live for all the application life.

i have an object wich will reference an istance if MyEntity with a particular id and that will call Notify() when a particular condition happen.

then there's another object wich reference a MyEntity with the same id to listen for event notification.

i set this reference into different session so the 2 MyEntity istances are different and the event behaviour is broken (i need to use the same istance to have a correct event handling)

What prevents your two objects from referencing the same MyEntity object?

I think you need to get a reference to the existing MyEntity instead of getting a new one from the database.

my esample is a lot simplified, in general i have a complex structure so i can't just get the object references with a navigation of objects graph.

also the order is not specified, so for example i can set before the MyEntity istance to an observer and then i set it to the root object.

OK. This seems to be more of a design issue than an NHibernate issue. Am I correct?

You could use a globally visible controller class that would be responsible for registering and unregistering notification event handlers. You could write an Interceptor that automatically handles registering the event when an object is retrieved.