openjpa-dev mailing list archives

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


Patrick Linskey commented on OPENJPA-407:

> Perhaps we need to add a document indicating that the hashCode
> and equals methods in JDBCFetchConfigurationImpl are used in
> querySQLCache for findBy operation. 

I'm a bit nervous about having equals() and hashCode() (which are by convention deemed to
apply to an entire instance) only be meaningful in certain contexts. I think that it would
make more sense to create some sort of inner cache key class whose equals() and hashCode()
are custom-designed for the purposes of this cache.

> Any other usage of hashCode/equals should consider the fetchInnderJoin? 

This change actually interfered with my OPENJPA-522 fix; I ended up switching to an IdentityHashMap
to avoid the issue. At the time, I did not realize that the addition of equals() / hashCode()
had caused this. I would not be surprised if there are other places in OpenJPA that implicitly
make assumptions about equals() and hashCode() behavior for FetchConfigurations, although
I can't think of any offhand.

In general, I'm not a huge fan of equals() / hashCode() methods (and especially hashCode())
that change in value over the lifecycle of the object; this tends to make it very hard to
put these types into data structures.

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

As I mentioned above, this seems fair for the purposes of  a cache key, but not appropriate
for the general equals() / hashCode() implementation for the instance.

> 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