Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <278607896.1248397877878.JavaMail.jira@brutus>
Date: Thu, 23 Jul 2009 18:11:17 -0700 (PDT)
From: "Ravi P Palacherla (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-1163) Data consistency issues while
 modifying collections.
In-Reply-To: <1590610513.1247067194839.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ravi P Palacherla commented on OPENJPA-1163:
--------------------------------------------

Hi Mike,

Thanks a lot for spending your time on this.

>> It's very interesting that the behavior is different when you add more changes (exceed 10).

CollectionChangeTrackerImpl.add() and remove() methods should give more info about this.
If the number of added objects plus the number of removed objects are greater than collection size, ChangeTracker is forcefully disabled.
If ChangeTracker is disabled, OpenJPA update strategy is delete all and re-insert all objects.
So while insert-all it can not see the objects inserted as part of em2 ( in my sample).
Hence this bug.

>> What bothers me about it is that you've updated a versioned entity (newA and result2) twice but didn't get an Optimistic Lock Exception. 

Excellent concern.
I was thinking previously that AItem objects modified in tran 1 and tran 2 does not interfere with each other and hence should not result in optimistic lock excpetion.
Now I understand that both tran 1 and tran 2 are working on same row of A , which mean at the time of tran1 commit I should get optimistic lock exception.

I verified the reason why I am not getting optimistic lock exception and I changed the method level version annotation to field level.
Now I got optimistic lock errors when I set the version annotation on field rather than on method.
I think version annotation on methods has some issue.

With version annotation on method, when I check the db tables then I do not see the corresponding version column.
After adding version attribute to the field I can see version column on the table and getting optimistic lock exception.

So in my example, both A and AItems are treated as non versioned entities.

In the process of answering your concerns, I realized that I definitely have to revisit my testcase.
I will try to modify the test case such that it properly demonstrates the current issue.
I think the issue defined in this JIRA is valid but my test case needs to be revisited.
Do you agree with this ?

Thanks again,
Ravi.

> Data consistency issues while modifying collections.
> ----------------------------------------------------
>
>                 Key: OPENJPA-1163
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1163
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 2.0.0
>         Environment: openJPA trunk. Derby DB.
>            Reporter: Ravi P Palacherla
>            Assignee: Ravi P Palacherla
>             Fix For: 2.0.0
>
>         Attachments: OPENJPA-1163_trunk.patch
>
>
> There are data consistency issues when modifying more number of elements in a collection Vs less number of elements.
> Following is a detailed explanation about the issue with example:
>  
> - Entity A has a collection of Entities AItems with cascade ALL.
> - Test case :
>   Clear all the data inside tables representing Entity A and AItems.  
>   Create 3 entity managers em1,em2 and em3.
>    
>   em1.begin()
>       create A on em1 with id "1"
>       add 10 elements of AItems (id's from 0-9) to the created A(id 1).
>       persist A.
>   em1.commit()
>  
>   em1.begin()
>       merge A ( created in the previous step)
>       Remove 3 elements of AItems from the merged A.
>       Add 3 elements of AItems ( id's 10,11,12) to the merged A (id 1).
>    
> With out committing em1
>    
>   em2.begin()
>       query database to fetch A and construct object result2 of entity A.
>       Add 3 elements of AItems ( id's 13,14,15) to fetched A ( result2)      
>    em2.commit ()
>    em1.commit()
>    
>   em3.begin()
>      query database to check the size of AItems that are related to A ( id 1)
>   em3.commit()
>    
>   The result on em3's query for AItems related to A, returns 13 as expected.
>   13 ( Initial 10 - em1's 3 + em1's 3 + em2's 3).
>    
> When the same test case is repeated with removing and adding 10 elements instead of 3 as before then I get wrong results.
>    
>     Add initial 10 AItems (id's 0-9) for A.
>     commit()
>    
>     em1 will remove 10 AItems from the collection of A.
>     em1 will add 10 AItems (id's 10-19) to collection of A.
>    
>     em2 will add 10 AItems (id's 20-29) to collection of A.
>    
>     Commit em2.
>     Commit em1.
>    
>     Then instead of 20 elements ( Initial 10 - em1's 10 + em1's 10 + em2's 10), I see only 10 elements.
>    
>     The 10 elements that I see are from em1's added AItems ( id's 10-19).
> I think the cause of the issue is that, when more number of elements (compared to initial element count of collection) in a collection are modified then collection tracking is disabled and openJPA tries to do the following:
>  -- Delete every thing from the collection
>  -- Insert data back to collection.
> While Inserting the data back it does not consider adding the dirty records ( em2's 10 added elements ) because the collection tracking is disabled.

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