You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Fernando (JIRA)" <ji...@apache.org> on 2008/12/10 00:02:44 UTC
[jira] Created: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
---------------------------------------------------------------------------------------
Key: OPENJPA-820
URL: https://issues.apache.org/jira/browse/OPENJPA-820
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 2.0.0
Reporter: Fernando
Priority: Critical
Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
I am trying to run the simple query below, against 2 slices.
select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
These are the two queries run on the low level databases:
SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by Fernando Padilla <fe...@alum.mit.edu>.
cool.. but what I was getting at..
Do you have any ideas what the test case could be? It is an
intermittent error.. would you have any clues as to what could force
this to happen, to make it consistently reproduceable?
I am assuming that you already have a test for a simple query, what else
can I test for? Have it execute the query 30 times until it fails?
But I'll review your unit test I suppose.. maybe there is a slight
nuance there..
but again, does your gut have any tips?
Pinaki Poddar wrote:
>> So, now that I have your attention, let's start to discuss.. what do you
> think it could be?
>
> Please post a reproducible JUnit test case without the scaffolding. It
> will help us to pinpoint the issue.
>
>> how come your unit tests didn't catch the other bugs that I filed?
>
> I am working towards that day when my unit tests will find all the bugs ;)
> Also that is why your hard work is much more appreciated.
> You can see for yourself the existing test cases for Slice in svn repository
> and you are welcome to contribute new ones. But I agree that test coverage
> needs improvement -- and contributions are very welcome.
>
>
>
Re: [jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by Fernando Padilla <fe...@alum.mit.edu>.
actually.. we are up against a rock and a hard place.
When you turn on Multithreaded support, all queries hang. This is
probably because the main DistributedQuery gets a lock, but then spawns
all of the sub queries in other threads and each of those try to get
locks, and voila, deadlock??
Fernando Padilla wrote:
> So.. could this be related to Multithreaded support??
>
> Since I have it turned off, but in reality because slices executes
> queries in parallel under the covers, then those queries require
> Multithreaded support..
>
> could this be the reason we're seeing weird intermittent errors??
>
> Pinaki Poddar wrote:
>>> So, now that I have your attention, let's start to discuss.. what do you
>> think it could be?
>>
>> Please post a reproducible JUnit test case without the scaffolding. It
>> will help us to pinpoint the issue.
>>
>>> how come your unit tests didn't catch the other bugs that I filed?
>>
>> I am working towards that day when my unit tests will find all the
>> bugs ;) Also that is why your hard work is much more appreciated. You
>> can see for yourself the existing test cases for Slice in svn repository
>> and you are welcome to contribute new ones. But I agree that test
>> coverage
>> needs improvement -- and contributions are very welcome.
>>
>>
>>
Re: [jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by Fernando Padilla <fe...@alum.mit.edu>.
So.. could this be related to Multithreaded support??
Since I have it turned off, but in reality because slices executes
queries in parallel under the covers, then those queries require
Multithreaded support..
could this be the reason we're seeing weird intermittent errors??
Pinaki Poddar wrote:
>> So, now that I have your attention, let's start to discuss.. what do you
> think it could be?
>
> Please post a reproducible JUnit test case without the scaffolding. It
> will help us to pinpoint the issue.
>
>> how come your unit tests didn't catch the other bugs that I filed?
>
> I am working towards that day when my unit tests will find all the bugs ;)
> Also that is why your hard work is much more appreciated.
> You can see for yourself the existing test cases for Slice in svn repository
> and you are welcome to contribute new ones. But I agree that test coverage
> needs improvement -- and contributions are very welcome.
>
>
>
Re: [jira] Commented: (OPENJPA-820) slices: a simple query is
failing (unique, but totally sending wrong parameters to SQL)
Posted by Pinaki Poddar <pp...@apache.org>.
> So, now that I have your attention, let's start to discuss.. what do you
think it could be?
Please post a reproducible JUnit test case without the scaffolding. It
will help us to pinpoint the issue.
> how come your unit tests didn't catch the other bugs that I filed?
I am working towards that day when my unit tests will find all the bugs ;)
Also that is why your hard work is much more appreciated.
You can see for yourself the existing test cases for Slice in svn repository
and you are welcome to contribute new ones. But I agree that test coverage
needs improvement -- and contributions are very welcome.
--
View this message in context: http://n2.nabble.com/-jira--Created%3A-%28OPENJPA-820%29-slices%3A-a-simple-query-is-failing-%28unique%2C-but-totally-sending-wrong-parameters-to-SQL%29-tp1636374p1641534.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: [jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by Fernando Padilla <fe...@alum.mit.edu>.
Thank you for responding.
> 3. What was that point about that *reproducible* test case again?
:) I know, you can give me shit about not having a reproducible test
case.. but that is why I believe documenting everything in jira is even
more important. I am documenting evidence of the bug, which someone
could argue should go there, so anyone that wants to try to fix the bug
can get all pertinent information..
So, now that I have your attention, let's start to discuss.. what do you
think it could be? Any ideas? Any other code I can review?
ps - how come your unit tests didn't catch the other bugs that I filed?
other very very simple queries, inserting of objects, sorting of
queries, etc.. Are the slices unit tests working properly?
Pinaki Poddar wrote:
> Hi,
>
>> I made comments on the bug itself, so we can document the whole issue:
> 1. We have maintained a distinction between JIRA and Nabble mail forum such
> that once an issue is sufficiently discussed in Nabble and matured then a
> corresponding JIRA issue is created. That does
> filter out conversational chatter (for which this Nabble forum is more
> suitable) and gives due importance to a JIRA issue that is classified as a
> critical bug.
>
> So you are requested a) to use this Nabble forum as you continue reporting
> the results of your experimentation
> b) consider raising JIRA issue, preferably with a reproducible test case
> because that is the best way for you to communicate the failed use case and
> also for us to attempt a resolution.
> c) choose between these two fora (Nabble and JIRA) according to the nature
> of communication.
>
> 2. > I'll try posting the "relevant portion of the failing use case", but I
> just did.
>
> I may have missed it amidst your words :) On an ideal day, I was looking for
> a reproducible JUnit Test case. But specifically I was looking for real code
> (not english description) that originates p0 and sets the parameter 'p0' to
> the query.
> Personally, I often find it more useful to generate a JUnit test case to
> isolate/debug a failing usage.
>
>> the annoying part, is that it seems intermittent :(
>> oI can't reproduce it at the moment :(
> 3. What was that point about that *reproducible* test case again?
>
Re: [jira] Commented: (OPENJPA-820) slices: a simple query is
failing (unique, but totally sending wrong parameters to SQL)
Posted by Pinaki Poddar <pp...@apache.org>.
Hi,
> I made comments on the bug itself, so we can document the whole issue:
1. We have maintained a distinction between JIRA and Nabble mail forum such
that once an issue is sufficiently discussed in Nabble and matured then a
corresponding JIRA issue is created. That does
filter out conversational chatter (for which this Nabble forum is more
suitable) and gives due importance to a JIRA issue that is classified as a
critical bug.
So you are requested a) to use this Nabble forum as you continue reporting
the results of your experimentation
b) consider raising JIRA issue, preferably with a reproducible test case
because that is the best way for you to communicate the failed use case and
also for us to attempt a resolution.
c) choose between these two fora (Nabble and JIRA) according to the nature
of communication.
2. > I'll try posting the "relevant portion of the failing use case", but I
just did.
I may have missed it amidst your words :) On an ideal day, I was looking for
a reproducible JUnit Test case. But specifically I was looking for real code
(not english description) that originates p0 and sets the parameter 'p0' to
the query.
Personally, I often find it more useful to generate a JUnit test case to
isolate/debug a failing usage.
> the annoying part, is that it seems intermittent :(
> oI can't reproduce it at the moment :(
3. What was that point about that *reproducible* test case again?
--
View this message in context: http://n2.nabble.com/-jira--Created%3A-%28OPENJPA-820%29-slices%3A-a-simple-query-is-failing-%28unique%2C-but-totally-sending-wrong-parameters-to-SQL%29-tp1636374p1641234.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: [jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I made comments on the bug itself, so we can document the whole issue:
https://issues.apache.org/jira/browse/OPENJPA-820
Please, any help would be greatly appreciated.
Pinaki Poddar wrote:
>> select this from com.protrade.fandom.data.entities.TeamFanJersey this
> where this.teamFan = :p0
> 1. What is the value of the query parameter 'p0'? If p0 is persisted in one
> slice only, then in other slices the query should compare with IS NULL.
>
>
> I had added a test case of the above form in
> ...openjpa.slice.TestQuery#testQueryParameterEntity. And that test verifies
> proper parameter binding and returns the correct result.
>
> May be something more is happening in your use case. Post the relevant
> portion of the failing use case.
>
Externalizer bug in ReflectingPersistenceCapable
Posted by Marek Mosiewicz <ma...@jotel.com.pl>.
I try Externalizer with no enhancing on OpenJPA 1.2.0 and it seems that it
does not work on persist. I found same situtation in here
http://www.mail-archive.com/users@openjpa.apache.org/msg01252.html
After some debuging it I found that ReflectingPersistenceCapable does use
getTypeCode not getDeclaredTypeCode on field metadata for pcProvideField
and pcReceiveField methods. In my case getTypeCode is 8 (String) which is
type of database field. The getDeclaredTypeCode returns 9 (Object) and it
seems to be correct type.
PCEnahcer uses GetDeclaredType in same methods.
Best regards,
Marek Mosiewicz
Re: [jira] Commented: (OPENJPA-820) slices: a simple query is
failing (unique, but totally sending wrong parameters to SQL)
Posted by Pinaki Poddar <pp...@apache.org>.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this
where this.teamFan = :p0
1. What is the value of the query parameter 'p0'? If p0 is persisted in one
slice only, then in other slices the query should compare with IS NULL.
I had added a test case of the above form in
...openjpa.slice.TestQuery#testQueryParameterEntity. And that test verifies
proper parameter binding and returns the correct result.
May be something more is happening in your use case. Post the relevant
portion of the failing use case.
--
View this message in context: http://n2.nabble.com/-jira--Created%3A-%28OPENJPA-820%29-slices%3A-a-simple-query-is-failing-%28unique%2C-but-totally-sending-wrong-parameters-to-SQL%29-tp1636374p1638566.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
[jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655421#action_12655421 ]
Fernando commented on OPENJPA-820:
----------------------------------
There, I got a run where it fails.
If you look at the log file and search for TEAMFANJERSEY, you will see the first SQL query:
SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
then the second:
SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
I can only assume that the first query was run against Slice1 (where TeamFanJersey is actually located), and the second against Slice2 (which is empty). Thus the query returns null.. which causes my code to create a TeamFanJersey (which happens to go into Slice2), which causes all future executions of the query above to return 2 TeamFanJersey objects.. a failure, so you'll see a tonne of exceptions through the rest of the log:
...NonUniqueResultException: The query on candidate type "class com.protrade.fandom.data.entities.TeamFanJersey" with filter "select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0" was configured to have a unique result, but more than one instance matched the query.
Let me know what else I can do to help us figure this out! :) :)
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
> Attachments: bad-log.txt
>
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pinaki Poddar updated OPENJPA-820:
----------------------------------
Component/s: (was: kernel)
slice
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: slice
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
> Attachments: bad-log.txt
>
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655405#action_12655405 ]
Fernando commented on OPENJPA-820:
----------------------------------
I'll try posting the "relevant portion of the failing use case", but I just did. There is a simple query, and it's failing, I already told you the query above, and pointed out the generated SQL that openjpa is executing against the slices.. and I have no clue how that would come about..
but here are more details.
I have two slices. One is the full database that I have been using for non-slice work. The second is a fully empty database with just the same schema, that I use for slices testing. So TeamFan and TeamFanJersey objects all exist in the same database.
In my code I am trying to do something like:
attainTeamFanJersey( TeamFan fan );
which then calls the query listed below, to see if there is a TeamFanJersey for that TeamFan. If null, then it creates one.
select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
What I expect is that it will always return a value since I KNOW that a TeamFan and TeamFanJersey both exist in Slice1.
For some reason OpenJPA returns null randomly, thus for some reason OpenJPA can't find a valid TeamFanJersey, even though I know it exists. When I was looking at the logs, that's when I saw the weird case that it seemed to be checking for NULL instead of the propery TeamFan id for one of the two slices.. weird.
When this happens, then my code assume that there is no TeamFanJersey, then it creates one. But now there are 2 TeamFanJersey objects related to that TeamFan.
Now the kicker. When the code creates a second TeamFanJersey, it properly creates that object. And at times it creates that on Slice2. But then when I execute the query again, at a later time ( same request, or another request ).
select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
It then finds BOTH TeamFanJersey objects.. which my code complains since it's expecting only 1 TeamFanJersey, not 2.. (getSingleResult).
So, here we are:
The query works most of the time, but seems to fail randomly.
The failure seems to be related to the low level SQL that it generates and runs against each Slice, in that it doesn't generate the same SQL.. weird.
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655397#action_12655397 ]
Fernando commented on OPENJPA-820:
----------------------------------
Pinaki Poddar wrote:
>> select this from com.protrade.fandom.data.entities.TeamFanJersey this
> where this.teamFan = :p0
> 1. What is the value of the query parameter 'p0'? If p0 is persisted in one
> slice only, then in other slices the query should compare with IS NULL.
>
>
> I had added a test case of the above form in
> ...openjpa.slice.TestQuery#testQueryParameterEntity. And that test verifies
> proper parameter binding and returns the correct result.
>
> May be something more is happening in your use case. Post the relevant
> portion of the failing use case.
>
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pinaki Poddar reassigned OPENJPA-820:
-------------------------------------
Assignee: Pinaki Poddar
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: slice
> Affects Versions: 2.0.0
> Reporter: Fernando
> Assignee: Pinaki Poddar
> Priority: Critical
> Attachments: bad-log.txt
>
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655008#action_12655008 ]
Fernando commented on OPENJPA-820:
----------------------------------
Alright, so it's not DistributedPreparedStatement, since this goes through the DistributedStoreQuery. So I have no clue to give you. Some how one of the slice queries loses the parameter....
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656668#action_12656668 ]
Fernando commented on OPENJPA-820:
----------------------------------
So it looks that this is caused by the ParallelExecutor executing the sub queries using multiple threads, without using proper locking: openjpa.Multithreaded=true. So it looks like the root cause of this bug is OPENJPA-825.
But I would keep this bug open until that is fixed..
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
> Attachments: bad-log.txt
>
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655398#action_12655398 ]
Fernando commented on OPENJPA-820:
----------------------------------
Question:
p0 is a persisted object, thus persisted in one slice. BUT I don't get your assertion that "then in other slices the query should compare with IS NULL." There is no reason to force this assertion in the code. Anyhow, where in the code would this behavior be applied? I might not be too smart or the code might be more complicated than I thought, but I have not seen anything that would do that.
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655407#action_12655407 ]
Fernando commented on OPENJPA-820:
----------------------------------
the annoying part, is that it seems intermittent :(
I can't reproduce it at the moment :(
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-820) slices: a simple query is failing
(unique, but totally sending wrong parameters to SQL)
Posted by "Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fernando updated OPENJPA-820:
-----------------------------
Attachment: bad-log.txt
huge log file, where it failed..
if you search for TEAMFANJERSEY, you will see the SQL that was executed against the Slices..
Slice1 has all the data, Slice2 is empty.
> slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
> Attachments: bad-log.txt
>
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null, while the query run against Slice2, knows the proper value of the parameter. This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver logging).
> I guess it's another bug in the DistributedPreparedStatement not properly setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.