Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 21 Nov 2007 09:25:38 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Fwd: [jira] Commented: (OPENJPA-446) Problem when setting String
 fields of detached objects
Sender: Craig.Russell@Sun.COM
To: dev@openjpa.apache.org
Message-id: <A4CC4578-12F5-4699-AA1C-AA43DF696E70@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-133-462890543; micalg=sha1
References: <7465812.1195587283008.JavaMail.jira@brutus>

--Apple-Mail-133-462890543
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=WINDOWS-1252;
	delsp=yes;
	format=flowed

First, thanks for the patch and all the work on debugging.

A couple of comments on the JIRA stuff...

1. If a patch is submitted without granting license to Apache, then =20
it needs to be resubmitted (as was done here) with the license grant.

2. A patch can be resubmitted under the same name, and JIRA figures =20
out that only the latest is to be used. The other one is grayed out =20
so you have to think twice about downloading it.

3. The submitter of a patch can remove the patch. I can't verify this =20=

but the original submitter should be able to. If there is a problem, =20
we can fix JIRA to allow it.

Craig

Begin forwarded message:

> From: "Patrick Linskey (JIRA)" <jira@apache.org>
> Date: November 20, 2007 11:34:43 AM PST
> To: dev@openjpa.apache.org
> Subject: [jira] Commented: (OPENJPA-446) Problem when setting =20
> String fields of detached objects
> Reply-To: dev@openjpa.apache.org
>
>
>     [ https://issues.apache.org/jira/browse/OPENJPA-446?=20
> page=3Dcom.atlassian.jira.plugin.system.issuetabpanels:comment-=20
> tabpanel#action_12544020 ]
>
> Patrick Linskey commented on OPENJPA-446:
> -----------------------------------------
>
> Thanks for the debugging work on this.
>
> Is it ok for us to put the DetachAttachTest.zip test files into =20
> OpenJPA under the ASL license?
>
>> Problem when setting String fields of detached objects
>> ------------------------------------------------------
>>
>>                 Key: OPENJPA-446
>>                 URL: https://issues.apache.org/jira/browse/=20
>> 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-=20=

>> fix.patch, DetachAttachTest.zip
>>
>>
>> I would like to report some strange behavior with detach and =20
>> merge. To me it looks like a bug.
>> I'm trying implement the following strategy:
>>
>> 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 =20
>> except in one situation. When committing the merge() (step 4) an =20
>> "optimistic locking error" is is thrown under the following =20
>> condition: (step 3) a (String) field is set to the same text that =20
>> it already contains but using a different String instance. In =20
>> other words, when the following expressions are true:
>>
>>     newString.equals(oldString)
>>     newString !=3D oldString
>> I have written some test code that reproduces this effect (see =20
>> 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 =20
>> instance:
>>   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
>>                 to the data store. The following objects may have =20
>> been
>>                 concurrently modified in another transaction:
>>                 [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 =20=

>> operator.
>> The expression can be false with the same text (but different =20
>> instances). I find this interesting as it matches exacly the =20
>> problematic condition. I think an .equals() would fix the issue I =20
>> am having. But I suppose there is something going wrong at another =20=

>> place as well.
>> 2. Here is the point where execution splits into different ways =20
>> when calling 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 =20
>> return a BitSet. So the condition is true.
>> In the tests that fail "ImplHelper.getUpdateFields(sm)" will =20
>> return null. So the condition is false.
>> Note: the problem persist with OpenJPA 1.1.0-SNAPSHOT. When run =20
>> without enhancing the Record class, all tests will succeed though =20
>> (printing this message =84INFO   [main] openjpa.Enhance - Creating =20=

>> subclass for "[class test.Record]". This means that your =20
>> application will be less efficient and will consume more memory =20
>> than it would if you ran the OpenJPA enhancer. Additionally, lazy =20
>> loading will not be available for one-to-one and many-to-one =20
>> persistent attributes in types using field access; they will be =20
>> loaded eagerly 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.
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


--Apple-Mail-133-462890543
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw
NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7
16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg
Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc
a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr
jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym
bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt
/CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6
eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMTIxMTcyNTM5WjAjBgkqhkiG9w0B
CQQxFgQUcZkRq8ECRJnMrnks4PFEFScwDy4wgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq
SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAMBz9EqMWbRTqoXZT/yJGTXLpsd0fNhW
xNEiTKzmU4rYUMRNBHDu9owRmSd0CP48RhqLcM6n5iE8Wja/2ecLQGTs6y/b+DAE/nK3dy5MsZbO
sm4Y/9/DJTrcXznDyWa8fJw9Jgg9504/7n0wsSUy1zjbaFqCJS7ovtFotmKtkaphS6FLncrwv51B
o3xDHsNtQwDCqHmLVRzsHESxYHRu+P64hZv4hLWHP/Mrg21PgvzJn+TLJpHAj/TcBjNSeYr7gxbv
6oXVdmWRMTCUT8bNZDvnEzv23u7U5W0kVq7IT0P4iQkUnD3XM0sEFeY3yDOmv54IFeaUaP+S+z6T
vBHEDs4AAAAAAAA=

--Apple-Mail-133-462890543--