[
https://issues.apache.org/jira/browse/OPENJPA-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592845#action_12592845
]
Fay Wang commented on OPENJPA-407:
----------------------------------
Hi Patrick,
Thank you for your comments.
(1) regarding the clearFetchGroups, you are right. We will set the
fetchGroupContainsDefault to true in this method.
(2) The querySQLCacheInstance in JDBCConfigurationImpl is a map of maps.
This map is hard coded as a HashMap, and can be accessed by multiple entity
mangers. The key in this map is the class of the context where the SelectImpl
is constructed, and the value is either CacheMap or ConcurrentCacheMap,
depending on the qerySQLCache configuration plugin. Addmittedly, this usage of
PluginValue is somehow different from the conventional usage.
Currently, the querySQLCacheInstance has three entries: (see the extra doc that
we attached earlier).
key: org.apache.openjpa.jdbc.kernel.JDBCStoreManager
value: CacheMap / ConcurrentCacheMap (depending on the plugin value of
querySQLCache)
key: org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy
value: CacheMap / ConcurrentCacheMap (depending on the plugin value of
querySQLCache)
key: org.apache.openjpa.jdbc.meta.starts.RelationFieldStrategy
value: CacheMap / ConcurrentCacheMap (depending on the plugn value of
querySQLCache)
(3) Regarding fetchInnerJoin, this field is newly added for JIRA-547, a fix
for dynamic query involving inner fetch join. The addInnerJoinFetch is only
called from JDBCStoreQuery. Since the patch we attached is for findBy only, and
we want to keep the caculation of hash code as simple as possible., this
fetchInnerJoin is therefore not in the calculation of the hashCode for
JDBCFetchConfigurationImpl. Perhaps we need to add a document indicating that
the hashCode and equals methods in JDBCFetchConfigurationImpl are used in
querySQLCache for findBy operation. Any other usage of hashCode/equals should
consider the fetchInnderJoin?
(4) As you suggested, we will keep the ordering of hashcodes and equals the
same.
(5) In terms of which fields will go into the calcuation of hashcode and
equals, we are considering those fields that can be changed at the runtime via
FetchPlan, since these will be directly affect the generated sql. For those
which could not be changed at runtime, we are not including them in the
hashcode or equals, hoping in doing so, we could minimize the effort in the
calculation of cache key.
> 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, OPENJPA-407.patch,
> OPENJPA-407.patch, QuerySQLCache.doc
>
>
> 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.
