nHibernate не зарежда свойства от трето ниво (кеширане без промиване)

Започнах да превключвам някакъв вече съществуващ код на nHibernate в базиран на Sharepoint ASP.NET проект от нетърпеливо зареждане и нова сесия при всяко посещение на базата данни към лениво зареждане и сесия за продължителността на HTTP заявката и започнах да се натъквам на проблем.

Когато създаваме елемент в тази система, има някои релации много към едно, които се попълват от падащи менюта. Това ни дава идентификатора, който е достатъчен за запазване в базата данни.

За да изпълним някои задачи след запазване, като известие по имейл, след това зареждаме същия елемент обратно, което преди това би ни попълнило цялото дърво на обектите.

Въпреки това, след промяната към отложено зареждане и сесия с продължителността на цялата заявка, получаваме NullReferenceExceptions от свойства под Item, които мистериозно са нулеви.

Зареждаме елемента през nHibernate в changesedItem. Обаждането, което е неуспешно, е:

changedItem.PaperMedia.FormsAnalyst.User.Contact.Name

PaperMedia е напълно попълнен, но всичко във FormsAnalyst е null, с изключение на ID.

Това е същото състояние, както когато го запазихме, така че една възможна причина за този проблем е, че елементът се кешира и просто се извлича, като по този начин nHibernate не познава действителните стойности от базата данни. Въпреки това, аз извършвам транзакцията, плюс изрично извикване на Flush() в сесията, между запазването и последващото зареждане, така че ако случаят е такъв, нито Commit(), нито Flush() нямат ефект върху кеша.

Промених тези свойства в съответните файлове hbm.xml на lazy="false" и имах SetFetchMode FetchMode.Eager също за всички тях, без ефект.

Също така обмислях max_fetch_depth като проблем. Ако извикам Refresh(changedItem) в сесията, това няма ефект. Ако обаче извикам Refresh(changedItem.PaperMedia), той ще се попълни чак до Name. Това изглежда отхвърля max_fetch_depth като проблем, но въпреки това направих опит да го увелича, като го зададох на 6 в hibernate.cfg.xml, както и SetProperty("max_fetch_depth", "6") в конфигурационния екземпляр докато създавате фабриката за сесии, и те също нямат ефект.

Не знам какво друго да пробвам.

Някой виждал ли е нещо подобно преди? Нов съм в nHibernate, така че може да е нещо просто...

Редактиране:

Изглежда, че кеширането наистина е проблемът. Извикването на Clear() на екземпляра на сесията коригира това поведение.

Така че въпросът сега става защо Flush() не актуализира кешираните елементи? Точно за това мислех, че е създаден да прави.


person Grank    schedule 13.01.2010    source източник
comment
FormsAnalyst генериран прокси клас ли е, когато това се случи? Не съм използвал max_fetch_depth, но мисля, че се отнася само за нетърпеливо зареждане.   -  person Jamie Ide    schedule 13.01.2010
comment
Да, може да сте прав, но не, това е действителен обект на UserAnalyst в този момент, тъй като нетърпеливо го зареждам в опит да накарам проблема да изчезне. Вярвам, че беше прокси обект, преди да започна да се забърквам с моите hbm.xml файлове и моите режими на извличане и други подобни, но не намерих комбинация, която да прави нещо различно от NullReferenceException и в двата случая.   -  person Grank    schedule 13.01.2010


Отговори (1)


Мисля, че Flush() е само за изпращане на промени в базата данни... той ще актуализира кеша с посочените обекти, ако те са били в паметта в този момент. Така че можете да използвате друга сесия или Clear()... или да попълните FormsAnalyst на първо място.

person fwalch    schedule 13.01.2010
comment
добре, попълването на децата на първо място не е чудесна опция, тъй като това е нов елемент, който потребителят създава, така че ще трябва да изпратя всички тези допълнителни данни на клиента и да ги накарам да ги изпратят обратно. Clear() работи добре в този сценарий, но причинява проблеми с бъдещото отложено зареждане с тази сесия след извикването на Clear(). Засега прибягнах до хакерския Refresh(changedItem.PaperMedia), но все още съм озадачен. Ако Flush() е само за изпращане на промени в базата данни, никога ли няма да върне промените? - person Grank; 15.01.2010