Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <429002292.1236873051260.JavaMail.jira@brutus>
Date: Thu, 12 Mar 2009 08:50:51 -0700 (PDT)
From: "Jeremy Bauer (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-878) Support default query hint for
 query timeout
In-Reply-To: <1318299626.1233252779605.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OPENJPA-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681365#action_12681365 ] 

Jeremy Bauer commented on OPENJPA-878:
--------------------------------------

Couple of comments on OPENJPA-878-20090311.patch (7:12pm).

1) There is quite a bit of duplication of the setTimeout method (likely caused by refactoring to eliminate the need for interface changes per previous comments) across multiple subclasses.  Is it possible to implement the method in the abstract parent class (for store query, seq, and strats) to eliminate much of the duplication?

or 

2) Similar to connection, could a decorator pattern be applied to prepared statement to decorate the ps with query and lock timeout  hints vs. calling it explicitly after a statement is constructed?  This may be difficult depending on the availability of the configuration.  Something to think about though.

3) The code uses 'max' to calculate the timeout value when query & lock timeout are used in combination.  Given the way lock timeouts are currently implemented (with query timeout), that seems like the safest behavior. (Other opinions?)  Until lock timeouts are handled by the DB, I think this behavior should be documented.  A sentence in the lock and query timeout docs would be sufficient.

4) Should query timeout be applied to sequence queries?  I'm on the fence.  Any thoughts on this?

Is anyone opposed to including the FIXME comments when these changes are committed?  They reference another JIRA so they aren't simply 'dangling' out there.  Is there a convention for commenting on future work within code?  Should those comments only exist within a JIRA?

> Support default query hint for query timeout
> --------------------------------------------
>
>                 Key: OPENJPA-878
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-878
>             Project: OpenJPA
>          Issue Type: Sub-task
>          Components: query
>    Affects Versions: 2.0.0
>            Reporter: Donald Woods
>            Assignee: Donald Woods
>             Fix For: 2.0.0
>
>         Attachments: OPENJPA-878-20090305-draft.patch, OPENJPA-878-20090306.patch, OPENJPA-878-20090310-eclipse.patch, OPENJPA-878-20090310.patch, OPENJPA-878-20090311-eclipse.patch, OPENJPA-878-20090311.patch, OPENJPA-878-20090311.patch, OPENJPA-878-docs-20090311.patch
>
>
> Support default query hint for query timeout as defined in section 3.6.4 of the spec.
> A new hint can be supplied for Java SE and Java EE environments -
>     javax.persistence.query.timeout // query timeout in seconds
> Can be used in the following:
>     Methods - Query.setHint()
>     Annotations (via QueryHint) - NamedQuery, NativeNamedQuery 
>     Properties - Persistence.createEntityManagerFactory, persistence.xml
> The following methods can return a javax.persistence.QueryTimeoutException: getResultList(), getSingleResult(), executeUpdate().
> If a QTE is thrown, the current transaction (if active) should not be marked for rollback.
> If the DB query timeout causes a rollback, then a PersistenceException should be thrown instead (see 3.6.1).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.