> If you don't want proxy you can set it in the mapping (lazy=false) Indeed, this completely solves the problem!
I will use this approach for now but it would be even better if I could find a solution where I don't need this additional configuration step. > > 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. I'm not sure if I can follow here. What harm could it do to check the cache before creating the proxy while hydrating an entity? It already checks the session cache so why not extend it to the second level cache as well? Anyway, the workaround solution that you proposed (i.e. check the cache and throw the exception only when real access to db is needed) would be fine as well but doesn't the "proxy wrapper" need a session in order to consult the cache? (with proxy wrapper I mean the dynamically generated proxy subclass) On 10 jul, 00:25, Fabio Maulo <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
