[
https://issues.apache.org/jira/browse/OPENJPA-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564824#action_12564824
]
Kevin Sutter commented on OPENJPA-407:
--------------------------------------
Thanks, Patrick, for the review. We are also performing some internal
performance tests. We'll let the team know how they go shortly... We're also
looking at other related improvements to this findBy path. We'll post a more
complete patch in the near future.
> Generally, the patch looks sound. I agree with Christiaan's concerns; we
> should probably change the caches to be configurable data structures.
I'm not convinced that a configurable data structure is necessary. We want the
performance of OpenJPA to be excellent "out of the box". We made a similar
decision when we decided to turn the Compilation Cache on by default. Maybe
that's what you mean... Make it configurable, but we can have it turned on by
default? If that's the case, then I'm okay with that approach.
> - JDBCStoreManager has a private configurable Map<ClassMapping,SelectImpl>.
> This might be a non-LRU CacheMap, and the configuration for it should be
> exposed via a JDBCConfiguration setting.
See above comments.
> - The Map<SelectImpl,SQLBuffer> is moved into SelectImpl itself, obviating
> the need for the second public map.
Yep, already figured that one out. Thanks.
Thanks again,
Kevin
> 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: findBy.patch, 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.
