[ 
https://issues.apache.org/jira/browse/OPENJPA-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535776
 ] 

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

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

Reply via email to