|
A B made changes - 23/Jun/05 02:24 PM
A B made changes - 23/Jun/05 02:25 PM
A B made changes - 23/Jun/05 04:54 PM
A B made changes - 24/Jun/05 12:56 AM
Oh, I should mention that the patch I created is against the 10.0 branch. I think we'll want it to be applied to all branches (10.0, 10.1, and trunk) but I don't know if there's a certain order that's supposed to be done. So I created the patch w.r.t the 10.0 branch and have marked the "Fixin" as 10.0.2.2". I'll work on adding the repro for this problem to one of the existing tests and will submit another patch for that later.
I looked at this patch... While it seems to solve the problem, I wonder if the recompile of the trigger action could use prepareStorable() method, instead of the newly extended prepare() method with internalSQL flag added. I think it is desirable to not have prepare() method with internalSQL flag, if possible, since this is mostly used directly for JDBC methods. These should ideally not need internalSQL option.
Thanks for looking at this Satheesh. Per your suggestion, I looked to see if I could use prepareStorable() instead of adding the new version of prepare(), and the answer was Yes, I could. However, after doing so, I noticed that once a recompilation was determined to be necessary, we would end up recompiling it EVERY time the trigger was fired thereafter (at least, that was the case with the repro I've attached to this issue). So I went back to square one to see how the trigger-action is compiled to begin with (upon first execution), and realized that we can and should be following that same codepath when we try to recompile the statement in mid-trigger processing.
Long story short, it turns out that this patch has become even simpler than it was before--all I had to do was replace my old changes with a single "if" statement in one class and the problem was solved. I'm attaching a new patch that does this; see the comments in the patch for an explanation of why this simple if-statement does the trick. So thanks again for the review--it's made for a much simpler patch, and one that seems like it's generally more correct--at least to me. If anyone else out there sees a problem with my approach, please comment. I'm attaching the new patch (based on 10.0 codeline) after running "derbylang" on Windows 2000 with Sun jdk 1.4.2 and seeing no failures. I will run the full "derbyall" suite tonight.
A B made changes - 24/Jun/05 07:34 AM
In looking more closely at the latest patch I posted, I decided to make a change that, while in theory should do the same thing in a more robust manner, is nonetheless enough to warrant a new run of "derbyall" before posting. So I have removed the old patch and will post a new one tomorrow, after my derbyall suite has completed.
A B made changes - 25/Jun/05 02:21 AM
patch v3 looks good to me.
I ported this fix from 10.0 branch into 10.1 branch and trunk. I noticed a test case has been added for this checkin. I will follow up with Army to get a test case added to each of the branches to make sure we don't break this fix in the future.
A B made changes - 30/Jul/05 07:54 AM
Submitted this change to trunk. Will merge into 10.1 after the release is done.
Sending java\testing\org\apache\derbyTesting\functionTests\master\triggerGeneral.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\triggerGeneral.sql Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\userDefMethods.java Transmitting file data ... Committed revision 226896.
Merged this test case addition into 10.1 release.
Sending java\testing\org\apache\derbyTesting\functionTests\master\triggerGeneral.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\triggerGeneral.sql Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\userDefMethods.java Transmitting file data ... Committed revision 227116. Fix for this issue was checked into the 10.0 (svn 201659), 10.1 (svn 219113) and trunk (svn 219115) branches. A test case was also added and committed to 10.1 (svn 227116) and the trunk (svn 226896) branch. Thus, I'm resolving and closing this issue.
A B made changes - 03/Aug/05 09:51 AM
A B made changes - 03/Aug/05 09:52 AM
reopening to fix fix version
Deepa Remesh made changes - 30/Sep/05 01:54 AM
Deepa Remesh made changes - 30/Sep/05 01:55 AM
Deepa Remesh made changes - 30/Sep/05 01:56 AM
Assigning to SQL component.
Rick Hillegas made changes - 11/Jul/06 11:56 PM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Intermittent failures when executing UPDATE trigger statements
The "intermittent" nature of the bug as first reported was because Derby didn't always choose to recompile the trigger statements, and hence the problem didn't always occur. I'm not sure how Derby goes about deciding when to automatically recompile the trigger, but in any event, I've written the repro to be more consistent: it forces a table alteration while running, which makes it mandatory for the trigger to be recompiled, and thus the problem is more easily reproduced.
I think I have a patch for this problem, but would like to run derbyall (tonight) before posting.