Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <33050951.1195601142994.JavaMail.jira@brutus>
Date: Tue, 20 Nov 2007 15:25:42 -0800 (PST)
From: "Jonas Petersen (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Updated: (OPENJPA-446) Problem when setting String fields of
 detached objects
In-Reply-To: <25628617.1195501963007.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/OPENJPA-446?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonas Petersen updated OPENJPA-446:
-----------------------------------

    Attachment: DetachAttachTest-updated.zip

Thanks for reviewing. It's fine for me if you put the DetachAttachTest.zip =
test files into OpenJPA under the ASL license. You may want to use the exte=
nded one that I just attached instead though. It also tests the null condit=
ions and does some assertion for each test.

> Problem when setting String fields of detached objects
> ------------------------------------------------------
>
>                 Key: OPENJPA-446
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-446
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jpa, kernel
>    Affects Versions: 1.0.1
>         Environment: OpenJPA 1.0.1
> Java 1.5.0_13
> MySQL Server 5.0
> MySQL Connector Java 5.0.6
>            Reporter: Jonas Petersen
>             Fix For: 1.0.2, 1.1.0
>
>         Attachments: detach-attach-fix-proper.patch, detach-attach-fix.pa=
tch, DetachAttachTest-updated.zip, DetachAttachTest.zip
>
>
> I would like to report some strange behavior with detach and merge. To me=
 it looks like a bug.
> I'm trying implement the following strategy:
> =20
> persistence context A:
>   1. get persistent object
>   2. detach the object
> no persistence context:
>   3. modify the (detached) object
> persistence context B:
>   4. attach (merge) the object
> This is quite simple and straight forward. It generally works except in o=
ne situation. When committing the merge() (step 4) an "optimistic locking e=
rror" is is thrown under the following condition: (step 3) a (String) field=
 is set to the same text that it already contains but using a different Str=
ing instance. In other words, when the following expressions are true:
>    =20
>     newString.equals(oldString)
>     newString !=3D oldString
> I have written some test code that reproduces this effect (see Attachment=
).
> The tests are using the same code except for one line:
> Test 1 sets the String to a different one than the object contains:
>     record.setContent("a text different than the one in the record");
> Test 2 sets the String to the same instance the object contains:
>   record.setContent(record.getContent());
> Test 3 sets the String to the same text but as a different String instanc=
e:
>   record.setContent(record.getContent()+"");
>  This is the result (output of the test run):
> ----------------------------------
> Test 1: SUCCESS
> Test 2: SUCCESS
> Test 3: FAILED (Optimistic locking errors were detected when flushing=20
>                 to the data store. The following objects may have been
>                 concurrently modified in another transaction:=20
>                 [test.Record-1])
> ----------------------------------
> While doing some debugging I noticed two things:
> 1. When setting the value:
> Class: org.apache.openjpa.kernel.DetachedStateManager
> Line: 555
> Method: settingStringField()
>         if (cur =3D=3D next || !_loaded.get(idx))
>           return;
> Here the old and the new value (String) is compared with the =3D=3D opera=
tor.
> The expression can be false with the same text (but different instances).=
 I find this interesting as it matches exacly the problematic condition. I =
think an .equals() would fix the issue I am having. But I suppose there is =
something going wrong at another place as well.
> 2. Here is the point where execution splits into different ways when call=
ing commit().
> Class: org.apache.openjpa.jdbc.kernel.AbstractUpdateManager
> Line: 151
> Method: populateRowManager()
>     } else if ((dirty =3D ImplHelper.getUpdateFields(sm)) !=3D null) {
> In the tests that succeed "ImplHelper.getUpdateFields(sm)" will return a =
BitSet. So the condition is true.
> In the tests that fail "ImplHelper.getUpdateFields(sm)" will return null.=
 So the condition is false.
> Note: the problem persist with OpenJPA 1.1.0-SNAPSHOT. When run without e=
nhancing the Record class, all tests will succeed though (printing this mes=
sage =E2=80=9EINFO   [main] openjpa.Enhance - Creating subclass for "[class=
 test.Record]". This means that your application will be less efficient and=
 will consume more memory than it would if you ran the OpenJPA enhancer. Ad=
ditionally, lazy loading will not be available for one-to-one and many-to-o=
ne persistent attributes in types using field access; they will be loaded e=
agerly instead.")
> Regards
> Jonas

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