[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] OneToMany list insert problem
|
Hi James,
I changed it to lazy loading and it does solve the problem. Thanks for the suggestion! I'll use that as the workaround.
Let me know if you want or need any other info related to the problem to help figure out why the eager case doesn't work.
Renee
On Feb 29, 2012, at 11:27 AM, Renee Revis wrote:
> Hi James,
>
> I showed the actual remove in a later message and then, trying to find a temporary workaround, the difference between a remove and a get. The remove case fails, the get is ok, so it seems to be a remove problem.
>
> The other messages explain in more detail what I'm seeing in the cache in relation to the transactions and the elements that are there/not there.
>
> I am using an OrderBy annotation. Isn't that the same thing as an OrderColumn?
>
> I'll try changing the EAGER to LAZY to see if it makes a difference.
>
> Renee
>
>
> On Feb 29, 2012, at 11:16 AM, James Sutherland wrote:
>
>>
>> I don't see in your code where you remove the element from the list?
>>
>> In general, since you are removing and adding to the list, you basically did
>> not change the relationship, so I would expect no changes at all, it is very
>> odd that the element is removed in the cache, was it there to begin with?
>> Ensure that you are maintain both sides of the relationship in general.
>>
>> I don't think changes to order are seen as changes unless you use an
>> OrderColumn, so you could try using that.
>>
>> EclipseLink has two modes of change tracking, one through events, and the
>> other through cloning. Because you relationship is EAGER it is using the
>> cloning method. You could try setting it to LAZY, to see if this is related
>> to the DEFERRED change tracking.
>>
>>
>>
>>
>> drrevis wrote:
>>>
>>>
>>> I have a bi-directional ManyToOne mapping between two entities. I
>>> maintain the order of the list on the OneToMany side based on a ranking
>>> field. Initially I can create the entities and everything is fine. After
>>> that, when I use a question line, I remove it from the list, update the
>>> ranking and then add it back into the list based on the new ranking value.
>>> I realize that the ManyToOne side is the owning side and it's up to me to
>>> maintain the list order in memory, and that's what I'm trying to do.
>>>
>>> Everything seems to work fine at first. Just before the EJB transaction
>>> finishes, I log the elements of the list and everything is as I expect.
>>> However, when I make the next request (i.e., a new EJB transaction), the
>>> list shows that the element was removed from the list, but never added
>>> back in. This doesn't match what it previously showed, however, in the
>>> first EJB transaction context.
>>>
>>> If I query the elements that are actually in the database, all of the
>>> elements are still there. And if I restart the server to force everything
>>> to be restored from the database, it all comes back as I expected (i.e.,
>>> with the element in the list and ordered as I expected), so it seems to be
>>> a caching issue somehow with the persistence context.
>>>
>>> Does anyone have any ideas as to what might be causing this problem and
>>> how to add the element back into the list correctly? I've tried a variety
>>> of things, and nothing has worked so far.
>>>
>>> Thanks for any help,
>>> Renee
>>>
>>>
>>>
>>> The relevant parts of the entities are:
>>>
>>> public class UserSelectorQuestionLine implements Serializable {
>>> private Integer ranking;
>>> @ManyToOne
>>> private UserSelectorQuestionGroup questionGroup;
>>> }
>>>
>>> and
>>>
>>> public class UserSelectorQuestionGroup implements Serializable {
>>> @OrderBy("ranking ASC")
>>> @OneToMany(fetch=FetchType.EAGER, mappedBy="questionGroup")
>>> private List<UserSelectorQuestionLine> questionLines;
>>> }
>>>
>>>
>>> And the routine I use to add an element into the list in the
>>> UserSelectorQuestionGroup class is:
>>>
>>> public void addUserSelectorQuestionLine(UserSelectorQuestionLine
>>> newUserSelectorQuestionLine) {
>>> int index=0;
>>> Random gen = new Random();
>>>
>>> if (this.questionLines.size() == 0) {
>>> this.questionLines.add(newUserSelectorQuestionLine);
>>> } else {
>>> for (UserSelectorQuestionLine nextQuestionLine :
>>> this.questionLines) {
>>> if (newUserSelectorQuestionLine.getRanking() <
>>> nextQuestionLine.getRanking()) {
>>> break;
>>> } else if
>>> (newUserSelectorQuestionLine.getRanking().equals(nextQuestionLine.getRanking()))
>>> {
>>> // We want to mix up the order of the question lines that
>>> have equal ranking
>>> if (gen.nextInt(2) == 1) {
>>> break;
>>> }
>>> }
>>> index++;
>>> }
>>> this.questionLines.add(index, newUserSelectorQuestionLine);
>>> }
>>> this.minRanking = questionLines.get(0).getRanking();
>>> }
>>>
>>> I know this routine is called and is working correctly because I can
>>> display the elements of the list after this is called and everything is as
>>> expected in the first EJB transaction context.
>>>
>>>
>>>
>>
>>
>> -----
>> http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
>> http://www.eclipse.org/eclipselink/
>> EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
>> TopLink
>> Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
>> http://wiki.oracle.com/page/TopLink TopLink
>> Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
>> http://www.eclipse.org/forums/index.php?t=thread&frm_id=111&S=1b00bfd151289b297688823a00683aca
>> EclipseLink
>> Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
>> Blog: http://java-persistence-performance.blogspot.com/ Java Persistence
>> Performance
>> --
>> View this message in context: http://old.nabble.com/OneToMany-list-insert-problem-tp33400445p33415163.html
>> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
