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 Wed, 17 Oct 2007 22:54:50 GMT


Patrick Linskey commented on OPENJPA-407:

The change was trivial: I changed the 'sql' local variable in SelectImpl.execute() to be a
member variable, and added a null check to control whether or not to go to the DBDictionary
to create a new one.

This depends on the original patch; the original patch lets us cache SelectImpls. Without
that patch, the SQLBuffer would always be uninitialized anyways.

I don't think that the lack of thread-safety in my prototype is an issue, since in the worst
case, we just end up over-creating SQLBuffers. However, I am concerned about the fact that
I'm ignoring the forUpdate and fetch parameters that are passed to execute(). I think that
it might be ok to ignore fetch, since I think it's the same as the one that was used to create
the SelectImpl, and is just being passed through for use by the DBDictionary. But I need to
look at that more closely, and also do the same analysis for the forUpdate statement.

But first I want to reproduce the numbers that I was seeing, to make sure that this is a worthwhile

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