openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar" <>
Subject RE: [jira] Updated: (OPENJPA-446) Problem when setting String fields of detached objects
Date Mon, 19 Nov 2007 23:04:31 GMT
Did you try the patch when current value of String field is null?

Looks like the patch should check for passed 'cur' being null. 

-----Original Message-----
From: Jonas Petersen (JIRA) [] 
Sent: Monday, November 19, 2007 2:57 PM
Subject: [jira] Updated: (OPENJPA-446) Problem when setting String
fields of detached objects

a.plugin.system.issuetabpanels:all-tabpanel ]

Jonas Petersen updated OPENJPA-446:

    Attachment: detach-attach-fix.patch

I have fixed the DetachedStateManager so it correctly compares the
strings (as described in "1. When setting the value:").

I have rebuilt OpenJPA and ran all maven tests successfully.

My DetachAttachTest runs all successfull as well now.

I'm attaching a patch.

> Problem when setting String fields of detached objects
> ------------------------------------------------------
>                 Key: OPENJPA-446
>                 URL:
>             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
>         Attachments: detach-attach-fix.patch,
> 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
> 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
>   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 ==
> 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.

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

View raw message