openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fay Wang (JIRA)" <>
Subject [jira] Commented: (OPENJPA-407) Cache SQL (or closer precursors to SQL) more aggressively
Date Mon, 28 Apr 2008 16:57:55 GMT


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

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:
>             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,
> 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.

View raw message