|
|
|
|
|
|
Re: Avoiding N+One Selects and stale BatchValueHolders [message #667431 is a reply to message #667406] |
Thu, 28 April 2011 17:17 |
Michael Nielson Messages: 15 Registered: April 2011 |
Junior Member |
|
|
The data that is used for the where clause of the BatchValueHolder won't necessarily be related to the relationship that returns incorrect results. For instance if I batch read notes on a query like this:
SELECT * FROM USERS WHERE NUMBEROFFRIENDS = 5;
If I do not immediately call getNotes on those users I have a potential problem. Here is the scenario:
A 2nd request comes in an says add one friend to User 12
A 3rd request comes in and says show me all of User 12's notes (A direct call for User 12 pulls the object out of the identity map)
User12.getNotes() then issues the query:
SELECT NOTES.* FROM NOTES, USERS WHERE NUMBEROFFRIENDS = 5;
This returns 0 notes for User12 because this user now has 6 friends.
I see just about any BatchValueHolder in the global IdentityMap as dangerous?
To avoid this we've stopped using BatchRead hints when we can't guarantee they will be immediately evaluated but that defeats the point of indirection.
Is there a way to change a value holder from a batch value holder back to a standard value holder before abandoning the object? What is the best way to avoid this?
Thanks for your help!
Michael
EDIT: The closer I look at bug 326197 the more I think it isn't perfectly related.
[Updated on: Thu, 28 April 2011 17:21] Report message to a moderator
|
|
|
|
Powered by
FUDForum. Page generated in 0.06292 seconds