You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Marcin Skladaniec <ma...@ish.com.au> on 2011/10/21 08:22:01 UTC
problem with ROP query performance
Hi
There is a discrepancy in behaviour of performQuery between ROP and
non-ROP setup.
lets consider this simple code:
DataContext newContext = ...
Artist artist = newContext.newObject(Artist.class);
newContext.commitChanges();
Painting painting = newContext.newObject(Painting.class);
painting.setArtist(artist);
assertEquals(artist.getPersistenceState(),
PersistenceState.MODIFIED); // this is true
SelectQuery sq = new SelectQuery(Painting.class,
ExpressionFactory.matchExp(Painting.ARTIST_PROPERTY, artist));
newContext.performQuery(sq);
I have added some logging to the performQuery() to check what happens.
This is what I see in ROP setup:
DEBUG - select query for Painting with qualifier: artist =
<ObjectId:Artist, id=200>
DEBUG - RelationshipQuery:paintings for: <ObjectId:Artist, id=200>
Seems straightforward, select query is executed... but then cayenne
faults the Artist object and its relationships. This would be ok, but
the Artist object is already in the context, no trip to the databse
required!
Same code in non-ROP setup does not behave teh same - the
RelatioshipQuery is not executed (unless artist.getPaintings() is called
explicitly).
For us this Relationship Query is a big big performance problem.
Is that a bug in ROP? Is there a way to prevent faulting of the relatioship?
With regards
Marcin
Re: problem with ROP query performance
Posted by Marcin Skladaniec <ma...@ish.com.au>.
I will Jira it, just will try to be more specific and include some code
or maybe unit test.
Thanks
Marcin
PS: using cayenne 3.1m2
On 27/10/11 5:22 AM, Andrus Adamchik wrote:
> Yeah sounds odd. It fetches paintings of that artist. Maybe we can jira that and take a closer look?
>
> On a side note, I noticed that due to the weak references used in the DataContext to store committed objects, you may see lots of faulting of objects that were fetched in the same context just a few seconds ago. This is probably completely unrelated, and for that we are experimenting with using soft references (instead of weak) via a new ObjectMapRetainStrategy (available in 3.1M3).
>
> Andrus
>
>
> On Oct 21, 2011, at 9:22 AM, Marcin Skladaniec wrote:
>
>> Hi
>>
>> There is a discrepancy in behaviour of performQuery between ROP and non-ROP setup.
>>
>> lets consider this simple code:
>>
>> DataContext newContext = ...
>>
>> Artist artist = newContext.newObject(Artist.class);
>> newContext.commitChanges();
>>
>> Painting painting = newContext.newObject(Painting.class);
>> painting.setArtist(artist);
>>
>> assertEquals(artist.getPersistenceState(), PersistenceState.MODIFIED); // this is true
>>
>> SelectQuery sq = new SelectQuery(Painting.class, ExpressionFactory.matchExp(Painting.ARTIST_PROPERTY, artist));
>>
>> newContext.performQuery(sq);
>>
>>
>> I have added some logging to the performQuery() to check what happens. This is what I see in ROP setup:
>>
>> DEBUG - select query for Painting with qualifier: artist =<ObjectId:Artist, id=200>
>> DEBUG - RelationshipQuery:paintings for:<ObjectId:Artist, id=200>
>>
>> Seems straightforward, select query is executed... but then cayenne faults the Artist object and its relationships. This would be ok, but the Artist object is already in the context, no trip to the databse required!
>>
>> Same code in non-ROP setup does not behave teh same - the RelatioshipQuery is not executed (unless artist.getPaintings() is called explicitly).
>>
>> For us this Relationship Query is a big big performance problem.
>> Is that a bug in ROP? Is there a way to prevent faulting of the relatioship?
>>
>> With regards
>> Marcin
>>
>>
Re: problem with ROP query performance
Posted by Emanuele Maiarelli <em...@mengozzi.com>.
What version is affected by this?
On Wed, 26 Oct 2011 22:22:36 +0300, Andrus Adamchik wrote:
> Yeah sounds odd. It fetches paintings of that artist. Maybe we can
> jira that and take a closer look?
>
> On a side note, I noticed that due to the weak references used in the
> DataContext to store committed objects, you may see lots of faulting
> of objects that were fetched in the same context just a few seconds
> ago. This is probably completely unrelated, and for that we are
> experimenting with using soft references (instead of weak) via a new
> ObjectMapRetainStrategy (available in 3.1M3).
>
> Andrus
>
>
> On Oct 21, 2011, at 9:22 AM, Marcin Skladaniec wrote:
>
>> Hi
>>
>> There is a discrepancy in behaviour of performQuery between ROP and
>> non-ROP setup.
>>
>> lets consider this simple code:
>>
>> DataContext newContext = ...
>>
>> Artist artist = newContext.newObject(Artist.class);
>> newContext.commitChanges();
>>
>> Painting painting = newContext.newObject(Painting.class);
>> painting.setArtist(artist);
>>
>> assertEquals(artist.getPersistenceState(),
>> PersistenceState.MODIFIED); // this is true
>>
>> SelectQuery sq = new SelectQuery(Painting.class,
>> ExpressionFactory.matchExp(Painting.ARTIST_PROPERTY, artist));
>>
>> newContext.performQuery(sq);
>>
>>
>> I have added some logging to the performQuery() to check what
>> happens. This is what I see in ROP setup:
>>
>> DEBUG - select query for Painting with qualifier: artist =
>> <ObjectId:Artist, id=200>
>> DEBUG - RelationshipQuery:paintings for: <ObjectId:Artist, id=200>
>>
>> Seems straightforward, select query is executed... but then cayenne
>> faults the Artist object and its relationships. This would be ok, but
>> the Artist object is already in the context, no trip to the databse
>> required!
>>
>> Same code in non-ROP setup does not behave teh same - the
>> RelatioshipQuery is not executed (unless artist.getPaintings() is
>> called explicitly).
>>
>> For us this Relationship Query is a big big performance problem.
>> Is that a bug in ROP? Is there a way to prevent faulting of the
>> relatioship?
>>
>> With regards
>> Marcin
>>
>>
--
Re: problem with ROP query performance
Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah sounds odd. It fetches paintings of that artist. Maybe we can jira that and take a closer look?
On a side note, I noticed that due to the weak references used in the DataContext to store committed objects, you may see lots of faulting of objects that were fetched in the same context just a few seconds ago. This is probably completely unrelated, and for that we are experimenting with using soft references (instead of weak) via a new ObjectMapRetainStrategy (available in 3.1M3).
Andrus
On Oct 21, 2011, at 9:22 AM, Marcin Skladaniec wrote:
> Hi
>
> There is a discrepancy in behaviour of performQuery between ROP and non-ROP setup.
>
> lets consider this simple code:
>
> DataContext newContext = ...
>
> Artist artist = newContext.newObject(Artist.class);
> newContext.commitChanges();
>
> Painting painting = newContext.newObject(Painting.class);
> painting.setArtist(artist);
>
> assertEquals(artist.getPersistenceState(), PersistenceState.MODIFIED); // this is true
>
> SelectQuery sq = new SelectQuery(Painting.class, ExpressionFactory.matchExp(Painting.ARTIST_PROPERTY, artist));
>
> newContext.performQuery(sq);
>
>
> I have added some logging to the performQuery() to check what happens. This is what I see in ROP setup:
>
> DEBUG - select query for Painting with qualifier: artist = <ObjectId:Artist, id=200>
> DEBUG - RelationshipQuery:paintings for: <ObjectId:Artist, id=200>
>
> Seems straightforward, select query is executed... but then cayenne faults the Artist object and its relationships. This would be ok, but the Artist object is already in the context, no trip to the databse required!
>
> Same code in non-ROP setup does not behave teh same - the RelatioshipQuery is not executed (unless artist.getPaintings() is called explicitly).
>
> For us this Relationship Query is a big big performance problem.
> Is that a bug in ROP? Is there a way to prevent faulting of the relatioship?
>
> With regards
> Marcin
>
>