Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Date: Fri, 18 Feb 2011 16:37:38 +0000 (UTC)
From: "Albert Lee (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Message-ID: 
 <1721004299.1139.1298047058759.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1900997266.54.1297976532879.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Updated: (OPENJPA-1943) Query timeout hint not honored
 consistently when pessimistic lock is issued to database requires
 multi-statements locking scheme
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/OPENJPA-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Albert Lee updated OPENJPA-1943:
--------------------------------

    Attachment: OPENJPA-1943.patch

> Query timeout hint not honored consistently when pessimistic lock is issued to database requires multi-statements locking scheme
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1943
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1943
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jpa, kernel
>    Affects Versions: 2.0.1, 2.1.0, 2.2.0
>            Reporter: Albert Lee
>            Assignee: Albert Lee
>             Fix For: 2.1.1, 2.2.0
>
>         Attachments: OPENJPA-1943.patch
>
>
> Query timeout and lock timeout values are stored in fetch plan/configuration. Due to semantic difference between the Query and em API, separate fetch plan/configuration objects are attached to QueryImpl and EntityManagerImpl. 
> When pessimistic lock is enforced by the provider to a query, if the underlying data base requires to generate multiple SQL statements, the timeout value from the QueryImpl is used to execute the data portion of the SQL statements but the timeout value from the EntityManagerImpl is used to issue the "FOR UPDATE" lock to the related table. This caused the discrepancy that the query timeout is NOT being honored. As a result, some database may wait forever and caused a "hung" scenario even the query timeout value is set. 
>     

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira