Environment description:
NHibernate v1.0.2.0
ASP.Net 2.0 with C#
Oracle 10g database server

Code between sessionFactory.openSession() and session.close():
I tried different approaches:

hql.Query() is just a simple class that builds a query like "From Driver dr where dr.FirstName = :FirstName".
The parameters are then bound to the corresponding properties criteriaDriver object.

The second try:


Another try:

... using the same hql class as in the first example, only this time the parameters are passed in with 2 arrays (Object[] for values and IType[] for types)

I also tried:


On to the problem:
I have a query that returns 5900 drivers, each has about 20 properties and an Iesi.Collections.ISet with distances. I (think I) use lazy loading correctly for this set. The first time I run this query, it returns in 1.5 seconds (which is acceptable), when I run the exact same query again, it takes 16 seconds to return!!! I timed the execution of the query's (so not including building up session and transaction) I would expect to see the execution time go down the second time!
Can anyone give me a clue to what I could be doing wrong?

I stumbled on the same problem. I guess it has something to do with your session. Close the session after you used it.
I think if you keep a session open all received objects put in a cache and that makes it slow.

If I close the session after my query, can I still use lazy loading? Now I have a single singleton data access object that holds 1 session. I connect the session before using and disconnect it after using. What's the cost of recreating the session? I tried this approach because of an article I read at theServerside.net...

I found a solution to keep working with the same session, but still get a serious performance gain! Now whenever I do a search or load an object, I clear my session first. This way I can still use lazy loading on the collections and I still get a huge performance boost! The updating and saving of the collections used to take over 30 seconds (even when only one property was changed), now it's a matter of milliseconds!
(Thanks basj for pointing me in the right direction)