openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-407) Cache SQL (or closer precursors to SQL) more aggressively
Date Wed, 17 Oct 2007 21:20:50 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535750
] 

Patrick Linskey commented on OPENJPA-407:
-----------------------------------------

The Select interface and its implementations are responsible for both assembling and executing
SELECT statements (and, for legacy reasons, some other statement types). So, it seemed as
though reusing the Select instances was the right level of abstraction.

My change actually isn't all that involved; it's mostly just a refactoring, and not much new
code. The refactoring was necessary because a bunch of things involved in SQL generation examined
a StateManager directly, and so to properly build a key for the Select, I needed to include
all those bits of information. I could have actually left most of the classes alone and just
made the key account for those bits of information, but I decided that that approach would
be error-prone, both up-front (what if I missed some state manager interrogation?) and moving
forward (what if the downstream methods started grabbing more data from the state manager?).

Additionally, my change does not currently actually cache the SQLBuffers generated within
the SelectImpls. It is possible that this is why there is no performance gain. The performance
loss in our tests might be attributable to the extra overhead of always computing all the
data needed for the SelectKey even if it's not needed in the end.

Also, note that my changes right now only are used when loading a single instance, not when
executing a Query. I expect that the techniques and implementation could be broadened to JPQL
cases as well, but I didn't really look at that use case, since the problem description seemed
to be identifying relation traversals and finds as the problems.

> I was actually thinking of scoping the cache to an EntityManager (broker) 
> instance. Maybe not as useful as across all active brokers, but we would 
> still gain a sizeable benefit (hopefully).

I think that the deciding factor for this will be whether or not there is any Broker-specific
state that must be involved in the caches.

> Cache SQL (or closer precursors to SQL) more aggressively
> ---------------------------------------------------------
>
>                 Key: OPENJPA-407
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-407
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: jdbc, kernel, query, sql
>    Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0
>            Reporter: Patrick Linskey
>             Fix For: 1.1.0
>
>         Attachments: OPENJPA-407.patch
>
>
> When data is not available in the data cache, OpenJPA dynamically creates SQL to look
up the requested data. OpenJPA should more aggressively cache this SQL to accelerate pathways
from a cache miss to the database.
> The generated SQL takes a number of factors into account, including the requested records,
transaction status, currently-loaded data, and the current fetch configuration. Any caching
would need to account for these factors as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message