openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-1163) Data consistency issues while modifying collections.
Date Wed, 05 Aug 2009 19:24:14 GMT

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

Michael Dick commented on OPENJPA-1163:
---------------------------------------

>    So, the end result is that the data inserted into database is dependent on the number
of modifications made on the collection.
>    I think it is bug as the data inserted into the database should be consistent irrespective
of the number of modifications
>    made to the collection. 

I agree, the number of modifications should not have an affect. 

> 2) When the data modified in two concurrent transactions does not interfere with each
other then both the transactions should win.
>    For example, let's consider table A which has 5 rows ( primary key of int 1-5) and
has row level locking.
>    Transaction 1 tries to modify rows 1 -3 and transaction 2 modifies 4-5 at the same
time.
>    In this case I think both the transactions has to win.

IMO this really depends on who owns the relationship or the collection. 

For example this model :
@Entity 
public class Manager {
    @OneToMany(mappedBy="manager")
    private Collection<Employee> employees;
}

@Entity
public class Employee { 
    @ManyToOne
    private Manager manager; 
}

Employee owns the relationship, and the employee table has a foreign key. Any Employees with
a FK -> a particular manager are considered that manager's Employees. In this case we should
see the behavior Ravi is advocating. 

The following example is slightly different : 
@Entity 
public class Manager {
    @OneToMany
    private Collection<Employee> employees;
}

@Entity
public class Employee { 
    // no reference to Manager.
}

In this case Manager is the owner of the relationship and the Manager object owns the relationship
and the set of Employees. In this case I'm less certain how we should behave. My original
take was that the last to commit wins - Manager owns the state of the relationship and bears
the sole burden of maintaining it. 

I'm not sure that's the ideal solution, but I didn't feel confident enough in the answer to
change the default. 

> 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
>         Environment: openJPA trunk. Derby DB.
>            Reporter: Ravi P Palacherla
>            Assignee: Ravi P Palacherla
>         Attachments: OPENJPA-1163_trunk.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> 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.


Mime
View raw message