Return-Path: 
 <dev-return-16018-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org>
Delivered-To: apmail-openjpa-dev-archive@www.apache.org
Received: (qmail 26671 invoked from network); 5 Apr 2010 16:00:50 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 5 Apr 2010 16:00:50 -0000
Received: (qmail 575 invoked by uid 500); 5 Apr 2010 16:00:50 -0000
Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org
Received: (qmail 435 invoked by uid 500); 5 Apr 2010 16:00:50 -0000
Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@openjpa.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@openjpa.apache.org>
List-Post: <mailto:dev@openjpa.apache.org>
List-Id: <dev.openjpa.apache.org>
Reply-To: dev@openjpa.apache.org
Delivered-To: mailing list dev@openjpa.apache.org
Received: (qmail 427 invoked by uid 99); 5 Apr 2010 16:00:50 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Apr 2010 16:00:50 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Apr 2010 16:00:48 +0000
Received: from brutus.apache.org (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 7652B234C495
	for <dev@openjpa.apache.org>; Mon,  5 Apr 2010 16:00:27 +0000 (UTC)
Message-ID: <1453708019.690021270483227483.JavaMail.jira@brutus.apache.org>
Date: Mon, 5 Apr 2010 16:00:27 +0000 (UTC)
From: "Fay Wang (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-1608) PESSIMISTIC_WRITE is not working
 in Informix
In-Reply-To: <470064947.638341270142787248.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


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

Fay Wang commented on OPENJPA-1608:
-----------------------------------

The pessimistic write lock can still be a potential problem for other databases where select for update is only effective in certain isolation levels. The current patch is to fix informix only.

> PESSIMISTIC_WRITE is not working in Informix
> --------------------------------------------
>
>                 Key: OPENJPA-1608
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1608
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 2.0.0, 2.1.0
>            Reporter: Fay Wang
>            Assignee: Fay Wang
>             Fix For: 2.0.0, 2.1.0
>
>         Attachments: OPENJPA-1608.patch
>
>
> The following call:
> 	district = em.find(DistrictJPA.class, key, LockModeType.PESSIMISTIC_WRITE);
> 	generates SELECT ... FOR UPDATE .
> 	However, in the default isolation level (read committed). Informix does not lock the row, causing a lot of duplicate key errors. The work around is for the application to explicitly set the property below in the persistence.xml:
> 	<property name="openjpa.jdbc.TransactionIsolation" value="repeatable-read" />
> 	According to the spec 3.4.4, footnote:
> 	For example, a persistence provider may use an underlying database platform's SELECT FOR UPDATE statements to implement pessimistic locking if that construct provides appropriate semantics, or the provider may use an isolation level of repeatable read.
> 	It appears that the persistence provider must implements PESSIMISTIC_WRITE semantics transparently to the application. 

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