If you don't want proxy you can set it in the mapping (lazy=false) and NH will check the cache immediately; perhaps is exactly what you are looking for in your scenario.
2009/7/9 Fabio Maulo <[email protected]> > I'm sorry but lazyLoading mean : verify what do as late as possible.We > can't check the cache before create a proxy, here I can say that is by > design and it will stay as is. > > What we can discuss is : before check the state of the session, perhaps, it > should check the cache and throw the exception only when real access to db > is needed. > > 2009/7/9 Tolomaüs <[email protected]> > > >> Hi Fabio, >> >> I see what you mean. >> >> But in my specific scenario, I have made sure that the cached entities >> are always available from the second level cache. So here it would >> make sense that NH first checks the second level cache before it >> creates a proxy (for the manager.Country in the example). And I don't >> think it would hurt those scenario's where the cache *can* become >> stale: first check the second level cache and if there is nothing or >> whatever there is is stale, only then create a proxy. >> >> Of course, for my specific scenario I could workaround this issue by >> calling NH.Initialize() on all lazy references to cached entities. >> >> Would you accept a patch if I can get this to work? >> >> Tolomaüs. >> >> On 9 jul, 17:06, Fabio Maulo <[email protected]> wrote: >> > I mean... >> > In practice to work with lazy relationships an opened session is >> *always*needed. >> > 2009/7/9 Fabio Maulo <[email protected]> >> > >> > >> > >> > > In lazy loading the check of the state of the session happen before >> know >> > > from where load the entity state (mean from cache or from db) for >> various >> > > reasons; for example NH can try the load from cache and discover that >> the >> > > state is stale and, at this point, an opened session is needed. >> > >> > > In practice to work with lazy relationships an opened session is ever >> > > needed. >> > >> > > 2009/7/9 Tolomaüs <[email protected]> >> > >> > >> Nobody has an idea? >> > >> > >> To summarize with a small example: >> > >> > >> I have a collection of Countries that are cached into the second >> level >> > >> cache >> > >> I have Managers that have a lazy reference to a Country >> > >> When I load a manager, I can read the manager.Country while the >> > >> session is open. But if I read it when the session is closed it gives >> > >> a lazy initialization exception. >> > >> > >> This leads me to assume that the manager.Country is loaded with a >> > >> proxy even though the country is available from the second level >> > >> cache. >> > >> > >> I will have a look at the code myself but if someone could point me >> in >> > >> the right direction I would greatly appreciate it. >> > >> > >> Thanks, >> > >> > >> Tolomaüs. >> > >> > >> On 18 jun, 23:05, Tolomaüs <[email protected]> wrote: >> > >> > Hi, >> > >> > >> > I'm in the middle of adding second level caching to an existing >> > >> > application and this is the first time that I really touch this - >> > >> > quite interesting - topic. >> > >> > >> > Basically, what I want to do in this first phase is to pre-load all >> > >> > referential data (i.e. the slowly changing stuff) when the session >> > >> > factory is created, both the entities and the queries. This should >> > >> > allow me to mark all references to these entities as lazy in the >> > >> > mappings of the "dynamic" entities and, moreover, I shouldn't have >> to >> > >> > eagerly load them anymore in queries on these "dynamic" queries. >> > >> > >> > So I hope to win both in performance and simplicity with this >> > >> > approach. >> > >> > >> > But now I stumbled on a problem when a dynamic entity (Leaver) with >> a >> > >> > reference to a referential entity (Role) is loaded, then the >> session >> > >> > is closed and after that the referential entity is touched. >> > >> > >> > This piece of code should make it more clear: >> > >> > >> > Leaver leaver; >> > >> > using (IUnitOfWork unitOfWork = OpenUnitOfWork()) >> > >> > { >> > >> > LeaverRepository leaverRepository = new >> > >> > LeaverRepository(unitOfWork); >> > >> > leaver = leaverRepository.RetrieveLeaver >> > >> > (leaverFNumber); >> > >> > } >> > >> > >> > Assert.IsTrue(NHibernateUtil.IsInitialized >> > >> > (leaver.Role)); // => FAILS! >> > >> > >> > Here is what the logging shows: >> > >> > DefaultLoadEventListener:0 - loading entity: [Role#LHR] >> > >> > DefaultLoadEventListener:0 - creating new proxy for entity <<== >> > >> > >> > So it seems that the second level cache is not checked when the >> Leaver >> > >> > is hydrated, resulting in a proxy. When the proxy is touched after >> the >> > >> > session is closed, the error occurs. >> > >> > >> > As said, the reference Leaver.Role is lazy and the referential >> entity >> > >> > is sitting in the second level cache. >> > >> > >> > If I load the Role from the second level cache into the session >> first, >> > >> > then there is no problem: >> > >> > >> > Leaver leaver; >> > >> > using (IUnitOfWork unitOfWork = OpenUnitOfWork()) >> > >> > { >> > >> > RoleRepository roleRepository = new RoleRepository >> > >> > (unitOfWork); >> > >> > roleRepository.RetrieveAll(); >> > >> > >> > LeaverRepository leaverRepository = new >> > >> > LeaverRepository(unitOfWork); >> > >> > leaver = leaverRepository.RetrieveLeaver >> > >> > (leaverFNumber); >> > >> > } >> > >> > >> > Assert.IsTrue(NHibernateUtil.IsInitialized >> > >> > (leaver.Role)); // => WORKS! >> > >> > >> > Logs: >> > >> > DefaultLoadEventListener:0 - loading entity: [Role#LHR] >> > >> > DefaultLoadEventListener:0 - entity found in session cache <<== >> > >> > >> > Is this by design or did I discover a bug? >> > >> > >> > Kind regards, >> > >> > >> > Tolomaüs >> > >> > > -- >> > > Fabio Maulo >> > >> > -- >> > Fabio Maulo >> >> >> > > > -- > Fabio Maulo > -- Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
