I have a general question about usage and behavior of Session and session.SetFlushMode.

We are using NHibernate 1.2.0.1 and SQL Server 2000, with .Net 2.0 in an Asp.Net application.

We are currently migrating a large stored procedure based web application to NHibernate using a Domain model, etc.
We started investigating some poor performance in the time it takes one of our pages to load. The page is used for administration purposes in our application. The page in question has a object hierarchy attached to is somewhat like this

PageControl is the parent
it then has a child Page which is a lazy loaded many to One Collection hanging off of Page

The Page collection (meaning all pages, contains 681 members)
is loaded into a drop down so that the user can change the Page that is associated to the PageControl object

On page reload(f5) we have noticed that the Page Collection is being flushed and reloaded, is the only way to turn this off by manually setting the the FlushMode to commit for this page?

we would like to keep the underlying nhibernate implementation away from the page logic but if this is our only option we'll have to do it.

Thanks
Eric

have you enabled the second-level cache on the Page collection? This would at least allow NH to check the cache before going back to the db. something like:


-devon

Here is what my mapping looks like


I have played with making the whole Page object cacheable in read-only mode and it doesn't seem to make a difference.

Any one else have any thoughts.

You would have to cache the query you use to retrieve the page list as well, since entity/collection cache only works for accesses by id.

post mapping files for PageControl and Page object. also, please post code you are using to load the PageControl object and populate the DropdownList. can be edited for brevity, no need to post everything.

Actually we have kind of fixed the issue, we had done something like this in our collection properties to make development a little easier


Became…

This does beg the question, how is everyone else handling adding items to collections of new entities?
It would be nice to just do something like

ParentItem item = new ParentItem();
item.ChildItems.Add(new ChildItem());

but that doesnt work when a child collection is null which it is on a new object

i don't think that is correct for an IList. I thought I remember reading somewhere that ILists do allow the addition of an element if the collection is null. Even so, I (needlessly) initialize the collection in my constructor:


and, when creating the Parent -> Child relationship:


actually, personally, i would change the constructor for the ChildItem to require the parent parameter (since the child cannot normally exist without the parent), thereby automatically setting both sides of the relationship:


don't forget, you really do need to manage both sides of the relationship. especially once you start implementing the second-level cache. if you do not set both sides of the relationship and the second-level cache is in play, your cached items will not be updated properly.

-devon

Actually we do manage both sides, my post was incomplete, sorry for any misunderstanding there.

The issue we were trying to address is that we seem to have create a new IList collection like so:


It seems that when we add code like this in our Property getters



We have an issue where NHibernate thinks that all of our collections are dirty when we for instance reload a page. And if we have a page that has a ChildObject and we are loading a drop down with 600 possible Parent objects it can get expensive.
I think mostly I am trying to understand the behavior of the underlying implementation and the ramifications of doing things like this.

Thanks

we are using lazy loaded collections so we are unable to add logic to our constructor as it jacks up the initialization of the proxied objects.

hmmm, i guess they way we get around that is to have a private default constructor that can only be used by NH and an overloaded constructor that is exposed to the developers:


this way NH can initialize the entity while still leveraging lazily-loaded collections, but i can also guarantee that the collection is instantiated properly when a developer creates the entity in code.

-devon

Great thanks for that tidbit.

actually Dynamic Proxy, and now NH (since 1.2) require the default constructor be public or protected, it complains if you try private.