openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <>
Subject [jira] Commented: (OPENJPA-407) Cache SQL (or closer precursors to SQL) more aggressively
Date Fri, 01 Feb 2008 16:53:08 GMT


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

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,

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