openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Fwd: [jira] Commented: (OPENJPA-446) Problem when setting String fields of detached objects
Date Wed, 21 Nov 2007 17:25:38 GMT
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  
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  
out that only the latest is to be used. The other one is grayed out  
so you have to think twice about downloading it.

3. The submitter of a patch can remove the patch. I can't verify this  
but the original submitter should be able to. If there is a problem,  
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  
> String fields of detached objects
> Reply-To: dev@openjpa.apache.org
>
>
>     [ https://issues.apache.org/jira/browse/OPENJPA-446? 
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment- 
> 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  
> OpenJPA under the ASL license?
>
>> 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.patch, 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:
>>
>> 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 one situation. When committing the merge() (step 4) an  
>> "optimistic locking error" 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 String instance. In  
>> other words, when the following expressions are true:
>>
>>     newString.equals(oldString)
>>     newString != 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  
>> 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  
>> 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 == next || !_loaded.get(idx))
>>           return;
>> Here the old and the new value (String) is compared with the ==  
>> operator.
>> 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 calling commit().
>> Class: org.apache.openjpa.jdbc.kernel.AbstractUpdateManager
>> Line: 151
>> Method: populateRowManager()
>>     } else if ((dirty = ImplHelper.getUpdateFields(sm)) != 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 enhancing the Record class, all tests will succeed though  
>> (printing this message „INFO   [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. Additionally, lazy  
>> loading will not be available for one-to-one and many-to-one  
>> persistent attributes in types using field access; they will be  
>> loaded eagerly instead.")
>> Regards
>> Jonas
>
> -- 
> 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!


Mime
View raw message