[
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.
