Hi Frank, With a few exceptions, to-one relationships can be restored without going to DB. Exceptions are:
1. Shared LRU object cache overflows and throws away some snapshots. 2. Relationship semantics means that target PK can not be fully derived from source snapshot. Try putting a breakpoint in DataDomainQueryAction.interceptRelationshipQuery - this should provide the answer to whether you are dealing with one of the above. Andrus > On May 17, 2016, at 11:50 PM, Frank Herrmann > <[email protected]> wrote: > > After digging some more, I think I know what is going on. It is more an > result of your second example. > > object2 = // something that fetches object2 > object1 = object2.getObject1(); // trips fault, fetches object1 > object2 = // refetch object2 from cache > object1 = object2.getObject1(); // trips fault, fetches object1 > object2 = // refetch object2 from cache > object1 = object2.getObject1(); // trips fault, fetches object1 > > The issue stems from the fact that the object2 in the cache is never > updated with the retrieved related objects. So, the next time we fetch > object2 from the object cache, it still have the fault. > > -Frank > > > > > On Tue, May 17, 2016 at 3:24 PM, Frank Herrmann < > [email protected]> wrote: > >> Thanks. That is pretty much our issue. If I do a prefetch however on >> object1 I everything works as expected. I'll have to dig deeper into our >> code to see what is going on. >> >> On Tue, May 17, 2016 at 2:48 PM, Michael Gentry <[email protected]> >> wrote: >> >>> Hi Frank, >>> >>> There might still be something more going on here. >>> >>> When you initially fetch object2 for the first time, the relationship to >>> object1 is a "fault" (assuming you don't prefetch). When you say >>> object2.getObject1(), Cayenne will trigger the fault resulting in a SELECT >>> statement sent to the DB, which gets populated into object1, which >>> replaces >>> the fault. The next time you say object2.getObject1(), it should return >>> object1 since the fault is no longer there. I glossed over a few things >>> there, but I hope you understood my gist. I'm assuming something has >>> happened to your object2 between the first and second calls to >>> getObject1() >>> which is causing the fault to be re-established and therefore re-tripped. >>> >>> mrg >>> >>> >>> >>> On Tue, May 17, 2016 at 2:29 PM, Frank Herrmann < >>> [email protected]> wrote: >>> >>>> I believe your first example. Here is some clarification. >>>> >>>> object2 = // something that fetches object2 -- object2 is now in the >>> object >>>> cache >>>> object1 = object2.getObject1(); // makes a call to the database and >>> fetches >>>> object1 -- does not put object1 in the object cache >>>> object1 = object2.getObject1(); // makes another call to the database to >>>> fetch object1, since object1 is not in the object cache >>>> >>>> -Frank >>>> >>>> On Tue, May 17, 2016 at 2:21 PM, Michael Gentry <[email protected]> >>>> wrote: >>>> >>>>> Hi Frank, >>>>> >>>>> I'm a little confused by this part: >>>>> >>>>> "If we retrieve Object2 from the database, it is placed in the object >>>>> cache. Afterwards, if we retrieve Object1 via the getter in Object2, >>>>> Object1 is not cached. So, every time we make the request for Object1 >>> via >>>>> the getter, another call is made to the database." >>>>> >>>>> Are you saying: >>>>> >>>>> object2 = // something that fetches object2 >>>>> object1 = object2.getObject1(); // trips fault, fetches object1 >>>>> object1 = object2.getObject1(); // trips fault, fetches object1 >>>>> >>>>> Or: >>>>> >>>>> object2 = // something that fetches object2 >>>>> object1 = object2.getObject1(); // trips fault, fetches object1 >>>>> object2 = // refetch object2 from cache >>>>> object1 = object2.getObject1(); // trips fault, fetches object1 >>>>> >>>>> Thanks, >>>>> >>>>> mrg >>>>> >>>>> >>>>> On Tue, May 17, 2016 at 9:32 AM, Frank Herrmann < >>>>> [email protected]> wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> I have a question regarding how Cayenne does caching. Right now, if >>> we >>>>>> retrieve an object from the database via Cayenne, it is placed in >>> the >>>>>> object cache. However, in our experience, if we then retrieve >>> another >>>>>> object via the relationship on the first object, it is not cached. >>>>>> >>>>>> A rough example: >>>>>> >>>>>> public class Object1 { >>>>>> ... misc attributes ... >>>>>> } >>>>>> >>>>>> public class Object2 { >>>>>> ... misc attributes... >>>>>> private Object1 object1; >>>>>> >>>>>> public Object1 getObject1() { >>>>>> return object1; >>>>>> } >>>>>> } >>>>>> >>>>>> If we retrieve Object2 from the database, it is placed in the object >>>>> cache. >>>>>> Afterwards, if we retrieve Object1 via the getter in Object2, >>> Object1 >>>> is >>>>>> not cached. So, every time we make the request for Object1 via the >>>>> getter, >>>>>> another call is made to the database. I have fixed this for >>> individual >>>>>> instances by using prefetches. However, our application is quite >>> large, >>>>> and >>>>>> I don't like the idea of tracking down case. >>>>>> >>>>>> Is there some way for Cayenne to place the relationship objects into >>>> the >>>>>> object cache the first time they are retrieved? We are using EhCache >>>> for >>>>>> our query caching, so if the object cache is not an options, is >>> there a >>>>> way >>>>>> to store these relationships in a short lived query cache? >>>>>> >>>>>> Thanks for the help. >>>>>> >>>>>> -Frank >>>>>> >>>>>> -- >>>>>> FRANK HERRMANN >>>>>> SOFTWARE ENGINEER >>>>>> >>>>>> T: 561-880-2998 x1563 >>>>>> >>>>>> E: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> [image: [ Modernizing Medicine ]] <http://www.modmed.com/> >>>>>> [image: [ Facebook ]] <http://www.facebook.com/modernizingmedicine> >>>>>> [image: >>>>>> [ LinkedIn ]] < >>> http://www.linkedin.com/company/modernizing-medicine/> >>>>>> [image: >>>>>> [ YouTube ]] <http://www.youtube.com/user/modernizingmedicine> >>>> [image: [ >>>>>> Twitter ]] <https://twitter.com/modmed_EMA> [image: [ Blog ]] >>>>>> <http://www.modmed.com/BlogBeyondEMR> [image: [ Instagram ]] >>>>>> <http://instagram.com/modernizing_medicine> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> FRANK HERRMANN >>>> SOFTWARE ENGINEER >>>> >>>> T: 561-880-2998 x1563 >>>> >>>> E: [email protected] >>>> >>>> >>>> >>>> [image: [ Modernizing Medicine ]] <http://www.modmed.com/> >>>> [image: [ Facebook ]] <http://www.facebook.com/modernizingmedicine> >>>> [image: >>>> [ LinkedIn ]] <http://www.linkedin.com/company/modernizing-medicine/> >>>> [image: >>>> [ YouTube ]] <http://www.youtube.com/user/modernizingmedicine> [image: >>> [ >>>> Twitter ]] <https://twitter.com/modmed_EMA> [image: [ Blog ]] >>>> <http://www.modmed.com/BlogBeyondEMR> [image: [ Instagram ]] >>>> <http://instagram.com/modernizing_medicine> >>>> >>> >> >> >> >> -- >> FRANK HERRMANN >> SOFTWARE ENGINEER >> >> T: 561-880-2998 x1563 >> >> E: [email protected] >> >> >> >> [image: [ Modernizing Medicine ]] <http://www.modmed.com/> >> [image: [ Facebook ]] <http://www.facebook.com/modernizingmedicine> [image: >> [ LinkedIn ]] <http://www.linkedin.com/company/modernizing-medicine/> [image: >> [ YouTube ]] <http://www.youtube.com/user/modernizingmedicine> [image: [ >> Twitter ]] <https://twitter.com/modmed_EMA> [image: [ Blog ]] >> <http://www.modmed.com/BlogBeyondEMR> [image: [ Instagram ]] >> <http://instagram.com/modernizing_medicine> >> >> > > > -- > FRANK HERRMANN > SOFTWARE ENGINEER > > T: 561-880-2998 x1563 > > E: [email protected] > > > > [image: [ Modernizing Medicine ]] <http://www.modmed.com/> > [image: [ Facebook ]] <http://www.facebook.com/modernizingmedicine> [image: > [ LinkedIn ]] <http://www.linkedin.com/company/modernizing-medicine/> [image: > [ YouTube ]] <http://www.youtube.com/user/modernizingmedicine> [image: [ > Twitter ]] <https://twitter.com/modmed_EMA> [image: [ Blog ]] > <http://www.modmed.com/BlogBeyondEMR> [image: [ Instagram ]] > <http://instagram.com/modernizing_medicine>
