Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-dev] When, in the roadmap, avoidance of useless flush will be implemented?

When, in the roadmap, avoidance of useless flush will be implemented?

I see lot of micro optimization been done in each iteration. 

Could it be possible that avoiding a single flush is 100x more
significant?

I see the following under this class:
http://fisheye2.atlassian.com/browse/~raw,r=4548/eclipselink/trunk/jpa/o
rg.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/EJBQ
ueryImpl.java


  protected Object executeReadQuery() {
        List parameterValues = processParameters();
        //TODO: the following performFlush() call is a temporary
workaround for bug 4752493:
        // CTS: INMEMORY QUERYING IN EJBQUERY BROKEN DUE TO CHANGE TO
USE REPORTQUERY.
        // Ideally we should only flush in case the selectionExpression
can't be conformed in memory.
        // There are two alternative ways to implement that:
        // 1. Try running the query with conformInUOW flag first - if it
fails with 
        //    QueryException.cannotConformExpression then flush and run
the query again -
        //    now without conforming.
        // 2. Implement a new isComformable method on Expression which
would determine whether the expression
        //    could be conformed in memory, flush only in case it
returns false.
        //    Note that doesConform method currently implemented on
Expression
        //    requires object(s) to be confirmed as parameter(s).
        //    The new isComformable method should not take any objects
as parameters,
        //    it should return false if there could be such an object
that
        //    passed to doesConform causes it to throw
QueryException.cannotConformExpression -
        //    and true otherwise.

The JavaDoc mention bug 4752493, which is in Oracle MetaLink but hidden.

I have concerns that my application previously using native EclipseLink
API will flush significantly more often when using JPA API. 

Extra useless flush means:
- walking the tree for change detection
- clone comparison if change tracking is not enabled
- latency of sending the changes to DB
- extra locks on certain DB
- need more DB connections

A fix would have to consider these other conform bugs:
- MetaLink bug 5849299 - SETSHOULDTHROWCONFORMEXCEPTIONS(0) API CAN'T
SUPRESS EXCEPTION
- MetaLink bug 7249967 - QUERY ENCOUNTERS TOPLINK-6089 BUT SHOULD BE
6074: CANNOT_CONFORM_EXPRESSION


Back to the top