[jira] Commented: (DERBY-3541) quit; on ij with authentication enabled does not shutdown the derby modules that are loaded
[ https://issues.apache.org/jira/browse/DERBY-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729545#action_12729545 ] V.Narayanan commented on DERBY-3541: Oystein says: "2. Somehow fix the case with authentication so that the database is shut down. (I am not sure how)" Although he does mean that it is difficult to shutdown the database when authentication is enabled (the same way shutdown is done when authentication is not enabled) he does not mean this is not a bug. Like in my comments before, ij is a generic jdbc front end tool, I am not happy with a derby specific call here at all. Ideally speaking you should be capable of using ij with any DB that supports a jdbc driver. If everyone agrees we can probably document that we need to shutdown DB's before quitting and prevent ij from going down without closing the DB's. That would be one probable solution. But again I am not sure I will be happy with such a crude fix. Here is my 2 paisa :) (IJ is a simple and elegant tool. There is a innocent simplicity to the tool that I would never want it to lose. If a user wants a sophisticated front end there are other options. We should not clutter ij unnecessarily.) > quit; on ij with authentication enabled does not shutdown the derby modules > that are loaded > --- > > Key: DERBY-3541 > URL: https://issues.apache.org/jira/browse/DERBY-3541 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.4.1.3 >Reporter: V.Narayanan >Priority: Minor > Attachments: derby.properties, PrintStackTrace.diff, > WithoutAuthentication_StackTrace.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4286) Need to evaluate test results from 10.3 soft upgrade to 10.5 on suites.all
[ https://issues.apache.org/jira/browse/DERBY-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729513#action_12729513 ] Lily Wei commented on DERBY-4286: - Thank you Kathey for looking at this. I look at the NetworkServerControl and there is no easy way to back port that to 10.3. We should resolve the issue. I am running more upgrade testing for 10.3 and 10.5 in turn of server and client. i.e. 10.3 server with 10.5 client and 10.5 server with 10.3 client. So far, the testing is going very well. Thank again fo all the help. > Need to evaluate test results from 10.3 soft upgrade to 10.5 on suites.all > -- > > Key: DERBY-4286 > URL: https://issues.apache.org/jira/browse/DERBY-4286 > Project: Derby > Issue Type: Improvement > Components: Test >Affects Versions: 10.3.3.0 >Reporter: Lily Wei >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby.log, dnn.out, rjall.zip, rjall.zip, ugall.out.zipx > > > Need to evaluate resultes from 10.3.3.0 release soft upgrade to 10.5 release. > There are expected failure from suites.all. I need help on analysis the test > results to make sure everything is all right. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-4286) Need to evaluate test results from 10.3 soft upgrade to 10.5 on suites.all
[ https://issues.apache.org/jira/browse/DERBY-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-4286. --- Resolution: Fixed > Need to evaluate test results from 10.3 soft upgrade to 10.5 on suites.all > -- > > Key: DERBY-4286 > URL: https://issues.apache.org/jira/browse/DERBY-4286 > Project: Derby > Issue Type: Improvement > Components: Test >Affects Versions: 10.3.3.0 >Reporter: Lily Wei >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby.log, dnn.out, rjall.zip, rjall.zip, ugall.out.zipx > > > Need to evaluate resultes from 10.3.3.0 release soft upgrade to 10.5 release. > There are expected failure from suites.all. I need help on analysis the test > results to make sure everything is all right. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4286) Need to evaluate test results from 10.3 soft upgrade to 10.5 on suites.all
[ https://issues.apache.org/jira/browse/DERBY-4286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729436#action_12729436 ] Kathey Marsden commented on DERBY-4286: --- Well, Lily. I think the reason for the authentication failure and subsequent hang is because the server requires authentication on shutdown now with 10.5. (DERBY-2109) I don't know how to work around that problem. We can't change the 10.3 tests to pass the user/password because the NetworkServerControl api that allows that does not exist with 10.3. I did try running the 10.5 tests with a 10.3 soft upgraded database and just got a lot of ROLES errors and then went back to 10.3 successfully, so I think that is as much testing as we can do. If there are no objections I will resolve this issue. > Need to evaluate test results from 10.3 soft upgrade to 10.5 on suites.all > -- > > Key: DERBY-4286 > URL: https://issues.apache.org/jira/browse/DERBY-4286 > Project: Derby > Issue Type: Improvement > Components: Test >Affects Versions: 10.3.3.0 >Reporter: Lily Wei >Assignee: Kathey Marsden >Priority: Minor > Attachments: derby.log, dnn.out, rjall.zip, rjall.zip, ugall.out.zipx > > > Need to evaluate resultes from 10.3.3.0 release soft upgrade to 10.5 release. > There are expected failure from suites.all. I need help on analysis the test > results to make sure everything is all right. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[ https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-4053: --- Attachment: mamtaDerby4053.java Recopying the standalone repro with correct name this time around. > suites.All hang with message java.net.BindException: Address already in use: > NET_Bind in derby.log > --- > > Key: DERBY-4053 > URL: https://issues.apache.org/jira/browse/DERBY-4053 > Project: Derby > Issue Type: Bug > Components: Network Server, Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden > Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log, > DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt, > javacore.20090211.123031.4000.0001.txt, mamtaDerby4053.java, suites.All.out > > > Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang > in the test run. The last test to run successfully was > xtestNestedSavepoints, but I am not sure exactly what test caused the hang. > I took a thread dump which I will attach, which showed network server up and > running but no ClientThread and a ping attempt blocked. > This hang is very similar to the hang that was seen after the fix attempts > for DERBY-1465 but that change was backed out so it is not related to that > change. It could be that the change for DERBY-1465 just made this highly > intermittent problem more likely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[ https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729427#action_12729427 ] Mamta A. Satoor edited comment on DERBY-4053 at 7/9/09 2:56 PM: I have a standalone repro of the problem which demonstrates the problem with local XA transaction. I am copying the comments from the program to descibe what it is doing. Next, I will add a test like this in our regression suite and put more comments in the Derby code changes. /** * This test does following * 1)Start the network server * 2)Start a local xa transaction * 3)Do not commit the local XA transaction * 4)Shutdown the network server * 5)Start the server again * * Before the fix for DERBY-4053 went in, step 4) would not shutdown the * server properly because of the pending local XA transaction. During the * server shutdown, we try to close all the open connections and close on * the XA connection results into an exception because there is still a * pending transaction. That exception is not handled by the server and * because of that, all the code necessary to shutdown the server is not * executed. The next time around, step 5), when we try to bring up the * server again, it ends up hanging * 2009-07-09 21:21:28.828 GMT : Invalid reply from network server: Insufficient data. * 2009-07-09 21:21:28.843 GMT : Could not listen on port 1527 on host 127.0.0.1: java.net.BindException: Address already in use: JVM_Bind * * The patch attached to the jira makes sure that before calling close on * local XA transaction, we first rollback any transaction active on the * connection. We should also work on server shutdown code to handle the * exceptions better so that it does not stop half way. * */ was (Author: mamtas): I have a standalone repro of the problem which demonstrates the problem with local XA transaction. I am copying the comments from the program to descibe what it is doing. Next, I will add a test like this in our regression suite and put more comments in the Derby code changes. /** * This test does following * 1)Start the network server * 2)Start a local xa transaction * 3)Do not commit the local XA transaction * 4)Shutdown the network server * 5)Start the server again * * Before the fix for DERBY-4180 went in, step 4) would not shutdown the * server properly because of the pending local XA transaction. During the * server shutdown, we try to close all the open connections and close on * the XA connection results into an exception because there is still a * pending transaction. That exception is not handled by the server and * because of that, all the code necessary to shutdown the server is not * executed. The next time around, step 5), when we try to bring up the * server again, it ends up hanging * 2009-07-09 21:21:28.828 GMT : Invalid reply from network server: Insufficient data. * 2009-07-09 21:21:28.843 GMT : Could not listen on port 1527 on host 127.0.0.1: java.net.BindException: Address already in use: JVM_Bind * * The patch attached to the jira makes sure that before calling close on * local XA transaction, we first rollback any transaction active on the * connection. We should also work on server shutdown code to handle the * exceptions better so that it does not stop half way. * */ > suites.All hang with message java.net.BindException: Address already in use: > NET_Bind in derby.log > --- > > Key: DERBY-4053 > URL: https://issues.apache.org/jira/browse/DERBY-4053 > Project: Derby > Issue Type: Bug > Components: Network Server, Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden > Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log, > DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt, > javacore.20090211.123031.4000.0001.txt, suites.All.out > > > Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang > in the test run. The last test to run successfully was > xtestNestedSavepoints, but I am not sure exactly what test caused the hang. > I took a thread dump which I will attach, which showed network server up and > running but no ClientThread and a ping attempt blocked. > This hang is very similar to the hang that was seen after the fix attempts > for DERBY-1465 but that change was backed out so it is not related to that > change. It could be that the change for DERBY-1465 just made this highly > intermittent problem more likely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[ https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-4053: --- Attachment: (was: mamtaDerby4180.java) > suites.All hang with message java.net.BindException: Address already in use: > NET_Bind in derby.log > --- > > Key: DERBY-4053 > URL: https://issues.apache.org/jira/browse/DERBY-4053 > Project: Derby > Issue Type: Bug > Components: Network Server, Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden > Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log, > DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt, > javacore.20090211.123031.4000.0001.txt, suites.All.out > > > Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang > in the test run. The last test to run successfully was > xtestNestedSavepoints, but I am not sure exactly what test caused the hang. > I took a thread dump which I will attach, which showed network server up and > running but no ClientThread and a ping attempt blocked. > This hang is very similar to the hang that was seen after the fix attempts > for DERBY-1465 but that change was backed out so it is not related to that > change. It could be that the change for DERBY-1465 just made this highly > intermittent problem more likely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[ https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-4053: --- Attachment: mamtaDerby4180.java I have a standalone repro of the problem which demonstrates the problem with local XA transaction. I am copying the comments from the program to descibe what it is doing. Next, I will add a test like this in our regression suite and put more comments in the Derby code changes. /** * This test does following * 1)Start the network server * 2)Start a local xa transaction * 3)Do not commit the local XA transaction * 4)Shutdown the network server * 5)Start the server again * * Before the fix for DERBY-4180 went in, step 4) would not shutdown the * server properly because of the pending local XA transaction. During the * server shutdown, we try to close all the open connections and close on * the XA connection results into an exception because there is still a * pending transaction. That exception is not handled by the server and * because of that, all the code necessary to shutdown the server is not * executed. The next time around, step 5), when we try to bring up the * server again, it ends up hanging * 2009-07-09 21:21:28.828 GMT : Invalid reply from network server: Insufficient data. * 2009-07-09 21:21:28.843 GMT : Could not listen on port 1527 on host 127.0.0.1: java.net.BindException: Address already in use: JVM_Bind * * The patch attached to the jira makes sure that before calling close on * local XA transaction, we first rollback any transaction active on the * connection. We should also work on server shutdown code to handle the * exceptions better so that it does not stop half way. * */ > suites.All hang with message java.net.BindException: Address already in use: > NET_Bind in derby.log > --- > > Key: DERBY-4053 > URL: https://issues.apache.org/jira/browse/DERBY-4053 > Project: Derby > Issue Type: Bug > Components: Network Server, Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden > Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log, > DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt, > javacore.20090211.123031.4000.0001.txt, mamtaDerby4180.java, suites.All.out > > > Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang > in the test run. The last test to run successfully was > xtestNestedSavepoints, but I am not sure exactly what test caused the hang. > I took a thread dump which I will attach, which showed network server up and > running but no ClientThread and a ping attempt blocked. > This hang is very similar to the hang that was seen after the fix attempts > for DERBY-1465 but that change was backed out so it is not related to that > change. It could be that the change for DERBY-1465 just made this highly > intermittent problem more likely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Kathey Marsden wrote: Rick Hillegas wrote: I think that this discussion has gotten seriously off-track. It is the intent of the standard that the offset and window length values be parameterized. This is clear from the standard language Hmmm, I thought the problem was that the standard did not allow for parameters and that is why we were having this discussion. Dag said: On the contra side, we have the fact that dynamic arguments are not allowed by the SQL standard for this construct, at least not yet. I have to admit I haven't had time to research the standard myself, but am a bit confused. Can you resolve your statement with Dag's? Other forms of parameterization are allowed by the standard. It is just that ? parameters are not explicitly included. The consensus of the committee members who discussed this was that this was an oversight, and no-one could explain why ? parameters had been omitted. The ? parameters would be, technically, an extension to what's in the standard--an extension which is compatible with the standard and which clearly fits the standard's intent. I believe this is a serious usability defect of our OFFSET/FETCH implementation. As it stands today, you can only scroll one of these windows forward by sacrificing the performance benefits of prepared statements. It would be a shame if this feature had to remain unusable until the next rev of the standard in 2011. If the committee approves some other language at that time, then we can implement that extension. I agree this would potentially improve performance but don't see it as a bug. Hopefully the statement cache will help. The statement cache does not help. Without the ? parameters, each window has to be constructed by a separate prepared statement. This is the crux of the problem. If people wish to veto this proposal, then I would ask them to propose an alternative solution which makes this feature usable and which they believe fits more comfortably within the intention of the standard. Hopefully it won't come down to a veto. Hopefully we can reach consensus in the community. Yes, please. I'm looking forward to consensus when I get back from vacation! Cheers, -Rick Kathey
[jira] Commented: (DERBY-4221) Provide message localizations for 10.5
[ https://issues.apache.org/jira/browse/DERBY-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729424#action_12729424 ] Rick Hillegas commented on DERBY-4221: -- Ported 792710 from trunk to the 10.5 branch at subversion revision 792716. > Provide message localizations for 10.5 > -- > > Key: DERBY-4221 > URL: https://issues.apache.org/jira/browse/DERBY-4221 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.1.2 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: changes.html, derby-4221-aa-01-stage1.diff > > > This JIRA collects localizations of messages created/changed by 10.5.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Rick Hillegas wrote: I think that this discussion has gotten seriously off-track. It is the intent of the standard that the offset and window length values be parameterized. This is clear from the standard language and I confirmed this with the SQL committee in May. For the record, Lance and I sit on the SQL committee as alternate delegates from Sun. Dynamic ? parameters are Derby's model for specifying parameters. I believe this is a serious usability defect of our OFFSET/FETCH implementation. As it stands today, you can only scroll one of these windows forward by sacrificing the performance benefits of prepared statements. It would be a shame if this feature had to remain unusable until the next rev of the standard in 2011. If the committee approves some other language at that time, then we can implement that extension. I agree with you Rick and I feel that we should implement this feature If people wish to veto this proposal, then I would ask them to propose an alternative solution which makes this feature usable and which they believe fits more comfortably within the intention of the standard. no veto from me, I am for it. -Lance Thanks, -Rick Dag H. Wanvik wrote: Hi folks, I have a working patch sitting on DERBY-4208. I am wondering if this is a fix we should consider including for 10.5.2? The pro argument is that this is a usability issue, and to the extent it forces the app to construct SQL on the fly, makes the app more vulnerable to injection attacks, at least in theory. A user has asked for it. On the contra side, we have the fact that dynamic arguments are not allowed by the SQL standard for this construct, at least not yet. Personally I think it's a nice extension. Thoughts? Dag
[jira] Commented: (DERBY-4221) Provide message localizations for 10.5
[ https://issues.apache.org/jira/browse/DERBY-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729422#action_12729422 ] Rick Hillegas commented on DERBY-4221: -- Tests passed cleanly for me. Committed derby-4221-aa-01-stage1.diff at subversion revision 792710. > Provide message localizations for 10.5 > -- > > Key: DERBY-4221 > URL: https://issues.apache.org/jira/browse/DERBY-4221 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.1.2 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: changes.html, derby-4221-aa-01-stage1.diff > > > This JIRA collects localizations of messages created/changed by 10.5.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Rick Hillegas wrote: I think that this discussion has gotten seriously off-track. It is the intent of the standard that the offset and window length values be parameterized. This is clear from the standard language Hmmm, I thought the problem was that the standard did not allow for parameters and that is why we were having this discussion. Dag said: On the contra side, we have the fact that dynamic arguments are not allowed by the SQL standard for this construct, at least not yet. I have to admit I haven't had time to research the standard myself, but am a bit confused. Can you resolve your statement with Dag's? I believe this is a serious usability defect of our OFFSET/FETCH implementation. As it stands today, you can only scroll one of these windows forward by sacrificing the performance benefits of prepared statements. It would be a shame if this feature had to remain unusable until the next rev of the standard in 2011. If the committee approves some other language at that time, then we can implement that extension. I agree this would potentially improve performance but don't see it as a bug. Hopefully the statement cache will help. If people wish to veto this proposal, then I would ask them to propose an alternative solution which makes this feature usable and which they believe fits more comfortably within the intention of the standard. Hopefully it won't come down to a veto. Hopefully we can reach consensus in the community. Kathey
[jira] Commented: (DERBY-3541) quit; on ij with authentication enabled does not shutdown the derby modules that are loaded
[ https://issues.apache.org/jira/browse/DERBY-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729414#action_12729414 ] Lily Wei commented on DERBY-3541: - Thank you, too. This is a good bug to look at. I mean that when authentication is enable, quit does not do shutdown. However, I don't see how quit can shutdown when authentication is enable. In such case, shutdown process will hit authentication failure error first before successfully shutting down the database. I think that is the point 2 on Oystin's point if I may quote him. > quit; on ij with authentication enabled does not shutdown the derby modules > that are loaded > --- > > Key: DERBY-3541 > URL: https://issues.apache.org/jira/browse/DERBY-3541 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.4.1.3 >Reporter: V.Narayanan >Priority: Minor > Attachments: derby.properties, PrintStackTrace.diff, > WithoutAuthentication_StackTrace.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4166) improvements to the mailjdbc test
[ https://issues.apache.org/jira/browse/DERBY-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729393#action_12729393 ] Kathey Marsden commented on DERBY-4166: --- - I think an argument like "samedb" would be better than upgrade, since sometimes you would want to resume with the same database without upgrade. - In DbTasks.java jdbcLoad we should add javadoc describing the parameters including the new one . I think a boolean useExistingdb would be better than upgrade, since it might be used on the same branch without upgrade. - I think for the useExistingdb option I think we should not attempt to run the schema.sql script. - I think instead of adding to_delete to the attach table for deletion we should maybe try just having a trigger that deletes from the attach table when we delete the mail from the inbox. - I think your database size method looks good but take out the commented old code. > improvements to the mailjdbc test > - > > Key: DERBY-4166 > URL: https://issues.apache.org/jira/browse/DERBY-4166 > Project: Derby > Issue Type: Improvement > Components: Test >Affects Versions: 10.6.0.0 >Reporter: Kathey Marsden >Priority: Minor > Attachments: Derby-4166.diff > > > When recently working with the mailjdbc system test > org.apache.derbyTesting.system.mailjdbc on DERBY-4152 I noticed some > potential improvements that might be good for the test. We should probably > hold off on these improvements however until the root cause of DERBY-4152 is > established, however, so we don't muddy the waters with that issue by > changing the test. > 1) DbTasks.moveToFolders may throw an IllegalArgumentException. > There is a line: message_id = Rn.nextInt(count - 1); > if count is 1 the argument to nextInt() might be 0 which is not allowed. I > hit this once but lost the stack trace, but it is apparent that when there is > only one row in the table this can occur. > > 2) Allow/implement multiple attachments per message and cleanup > DbTasks.insertMail() logic. >- Remove the attach_id column from INBOX to allow multiple attachments. >-Make the attachment insert part of the message for loop in insertMail. >Use getGeneratedKeys() to get the id of the inserted message. >When attachments are inserted, insert (1-4) attachments and give them a > corresponding attach_id from 1-4. > This will allow for removal of the select statements used to determine id and > attach_id. I'll file another issue for these improvements if folks agree > that they are sensible. > A detailed description of the current implementation of insertMail is > described at > https://issues.apache.org/jira/secure/attachment/12405685/insertMailSummary.txt > 3) DbTasks.databaseSize calculation is wrong. It doesn't match du -sk. The > method does not recurse into subdirectories and includes the length() on > directory files which is undefined accourding to the file.length() javadoc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
I think that this discussion has gotten seriously off-track. It is the intent of the standard that the offset and window length values be parameterized. This is clear from the standard language and I confirmed this with the SQL committee in May. For the record, Lance and I sit on the SQL committee as alternate delegates from Sun. Dynamic ? parameters are Derby's model for specifying parameters. I believe this is a serious usability defect of our OFFSET/FETCH implementation. As it stands today, you can only scroll one of these windows forward by sacrificing the performance benefits of prepared statements. It would be a shame if this feature had to remain unusable until the next rev of the standard in 2011. If the committee approves some other language at that time, then we can implement that extension. If people wish to veto this proposal, then I would ask them to propose an alternative solution which makes this feature usable and which they believe fits more comfortably within the intention of the standard. Thanks, -Rick Dag H. Wanvik wrote: Hi folks, I have a working patch sitting on DERBY-4208. I am wondering if this is a fix we should consider including for 10.5.2? The pro argument is that this is a usability issue, and to the extent it forces the app to construct SQL on the fly, makes the app more vulnerable to injection attacks, at least in theory. A user has asked for it. On the contra side, we have the fact that dynamic arguments are not allowed by the SQL standard for this construct, at least not yet. Personally I think it's a nice extension. Thoughts? Dag
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Kathey Marsden wrote:
Mike Matrigali wrote:
I would rather wait for an approved standard so that we don't later
get caught with apps depending on a non-standard behavior that we
might want to change in the future to meet a standard.
From the provided info it does not even look like there is a defacto
standard adopted by multiple db's.
I tend to agree that it is better to wait for a standard. This still
seems all over the place for the different database product
implementations and not yet even in a draft standard.
Well it is in the standard for 2008
::=
OFFSET { ROW | ROWS }
::=
FETCH { FIRST | NEXT } [ ] { ROW | ROWS } ONLY
So why not support it?
personally, if you can easily support some of the other variants, i
would do that as well. Just because something is not in an official
standard, it indirectly becomes a standard when implemented by multiple
vendors...
Don't get me wrong, standards are important, but so is making
applications easier to use and migrate from one platform to another
.02
Regards
Lance
Kathey
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Mike Matrigali wrote: I would rather wait for an approved standard so that we don't later get caught with apps depending on a non-standard behavior that we might want to change in the future to meet a standard. From the provided info it does not even look like there is a defacto standard adopted by multiple db's. I tend to agree that it is better to wait for a standard. This still seems all over the place for the different database product implementations and not yet even in a draft standard. Kathey
[jira] Commented: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[ https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729334#action_12729334 ] Kathey Marsden commented on DERBY-4053: --- Ahh, good news. > suites.All hang with message java.net.BindException: Address already in use: > NET_Bind in derby.log > --- > > Key: DERBY-4053 > URL: https://issues.apache.org/jira/browse/DERBY-4053 > Project: Derby > Issue Type: Bug > Components: Network Server, Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden > Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log, > DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt, > javacore.20090211.123031.4000.0001.txt, suites.All.out > > > Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang > in the test run. The last test to run successfully was > xtestNestedSavepoints, but I am not sure exactly what test caused the hang. > I took a thread dump which I will attach, which showed network server up and > running but no ClientThread and a ping attempt blocked. > This hang is very similar to the hang that was seen after the fix attempts > for DERBY-1465 but that change was backed out so it is not related to that > change. It could be that the change for DERBY-1465 just made this highly > intermittent problem more likely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[ https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729330#action_12729330 ] Mamta A. Satoor commented on DERBY-4053: Sorry, I wasn't completely awake when i posted on derby-dev that "Despite the change, I still get the hang". With my changes, I do not see the hang in jdbc4 suite. > suites.All hang with message java.net.BindException: Address already in use: > NET_Bind in derby.log > --- > > Key: DERBY-4053 > URL: https://issues.apache.org/jira/browse/DERBY-4053 > Project: Derby > Issue Type: Bug > Components: Network Server, Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden > Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log, > DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt, > javacore.20090211.123031.4000.0001.txt, suites.All.out > > > Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang > in the test run. The last test to run successfully was > xtestNestedSavepoints, but I am not sure exactly what test caused the hang. > I took a thread dump which I will attach, which showed network server up and > running but no ClientThread and a ping attempt blocked. > This hang is very similar to the hang that was seen after the fix attempts > for DERBY-1465 but that change was backed out so it is not related to that > change. It could be that the change for DERBY-1465 just made this highly > intermittent problem more likely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
I would rather wait for an approved standard so that we don't later get caught with apps depending on a non-standard behavior that we might want to change in the future to meet a standard. From the provided info it does not even look like there is a defacto standard adopted by multiple db's. /mikem Dag H. Wanvik wrote: Hi folks, I have a working patch sitting on DERBY-4208. I am wondering if this is a fix we should consider including for 10.5.2? The pro argument is that this is a usability issue, and to the extent it forces the app to construct SQL on the fly, makes the app more vulnerable to injection attacks, at least in theory. A user has asked for it. On the contra side, we have the fact that dynamic arguments are not allowed by the SQL standard for this construct, at least not yet. Personally I think it's a nice extension. Thoughts? Dag
[jira] Assigned: (DERBY-4221) Provide message localizations for 10.5
[ https://issues.apache.org/jira/browse/DERBY-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas reassigned DERBY-4221: Assignee: Rick Hillegas > Provide message localizations for 10.5 > -- > > Key: DERBY-4221 > URL: https://issues.apache.org/jira/browse/DERBY-4221 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.1.2 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: changes.html, derby-4221-aa-01-stage1.diff > > > This JIRA collects localizations of messages created/changed by 10.5.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4221) Provide message localizations for 10.5
[ https://issues.apache.org/jira/browse/DERBY-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4221: - Attachment: derby-4221-aa-01-stage1.diff As with the 10.4 message localizations (see DERBY-3804), I would like to divide the 10.5 work into two phases: 1) The first phase sorts the existing messages files by SQLState, eliminating the comments. The comments add no value since the documentation in messages.xml is more extensive. Sorting the messages makes phase (2) easy. 2) The second phase is the actual work of merging in the localizations. Attaching derby-4221-aa-01-stage1.diff. This accomplishes phase (1). For the engine localizations, there aren't many diffs and there are none for the DRDA localizations. That is because these files were sorted for 10.4. For the tools and sysinfo localizations, there are a lot of diffs because these files were not sorted for 10.4. As a sanity check, I am running the regression tests now. Touches the following files: M java/tools/org/apache/derby/loc/toolsmessages_it.properties M java/tools/org/apache/derby/loc/sysinfoMessages_ja_JP.properties M java/tools/org/apache/derby/loc/toolsmessages_ja_JP.properties M java/tools/org/apache/derby/loc/sysinfoMessages_zh_TW.properties M java/tools/org/apache/derby/loc/sysinfoMessages_de_DE.properties M java/tools/org/apache/derby/loc/sysinfoMessages_zh_CN.properties M java/tools/org/apache/derby/loc/toolsmessages_zh_TW.properties M java/tools/org/apache/derby/loc/sysinfoMessages_ko_KR.properties M java/tools/org/apache/derby/loc/toolsmessages_de_DE.properties M java/tools/org/apache/derby/loc/sysinfoMessages_fr.properties M java/tools/org/apache/derby/loc/sysinfoMessages_es.properties M java/tools/org/apache/derby/loc/toolsmessages_zh_CN.properties M java/tools/org/apache/derby/loc/toolsmessages_ko_KR.properties M java/tools/org/apache/derby/loc/sysinfoMessages_it.properties M java/tools/org/apache/derby/loc/toolsmessages_es.properties M java/tools/org/apache/derby/loc/toolsmessages_fr.properties M java/engine/org/apache/derby/loc/messages_de_DE.properties M java/engine/org/apache/derby/loc/messages_zh_CN.properties M java/engine/org/apache/derby/loc/messages_ko_KR.properties M java/engine/org/apache/derby/loc/messages_es.properties M java/engine/org/apache/derby/loc/messages_fr.properties M java/engine/org/apache/derby/loc/messages_it.properties M java/engine/org/apache/derby/loc/messages_ja_JP.properties M java/engine/org/apache/derby/loc/messages_zh_TW.properties > Provide message localizations for 10.5 > -- > > Key: DERBY-4221 > URL: https://issues.apache.org/jira/browse/DERBY-4221 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.1.2 >Reporter: Rick Hillegas > Attachments: changes.html, derby-4221-aa-01-stage1.diff > > > This JIRA collects localizations of messages created/changed by 10.5.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4221) Provide message localizations for 10.5
[ https://issues.apache.org/jira/browse/DERBY-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-4221: - Issue & fix info: [High Value Fix, Patch Available] (was: [High Value Fix]) > Provide message localizations for 10.5 > -- > > Key: DERBY-4221 > URL: https://issues.apache.org/jira/browse/DERBY-4221 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.1.2 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: changes.html, derby-4221-aa-01-stage1.diff > > > This JIRA collects localizations of messages created/changed by 10.5.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[ https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729312#action_12729312 ] Kathey Marsden commented on DERBY-4053: --- Hi Mamta, I took a look at DERBY4053_patch1_diff_July092009.txt. On visual inspection it seems like it should do what we want. There is an import of BrokeredConnectionControl in EmbedConnection which should be removed. In your mail to derby-dev, you said "Despite the change, I still get the hang. " Do you still get the InvalidReply? If you put the try/catch block around the shutdown operations, do you still see an exception? I did some grepping on the tests in jdbc4 and I think you are right that they only use local transactions. > suites.All hang with message java.net.BindException: Address already in use: > NET_Bind in derby.log > --- > > Key: DERBY-4053 > URL: https://issues.apache.org/jira/browse/DERBY-4053 > Project: Derby > Issue Type: Bug > Components: Network Server, Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden > Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log, > DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt, > javacore.20090211.123031.4000.0001.txt, suites.All.out > > > Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang > in the test run. The last test to run successfully was > xtestNestedSavepoints, but I am not sure exactly what test caused the hang. > I took a thread dump which I will attach, which showed network server up and > running but no ClientThread and a ping attempt blocked. > This hang is very similar to the hang that was seen after the fix attempts > for DERBY-1465 but that change was backed out so it is not related to that > change. It could be that the change for DERBY-1465 just made this highly > intermittent problem more likely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - Daily 792201 - Sun DBTG
[Auto-generated mail] *Daily* 792201/2009-07-08 18:02:22 MEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 01138911389 0 3297.89% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0226226 056.02% derbyall 022 0 516.78% compatibility 022 0 .% demoSuite sles 01138911389 0 2049.20% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0226226 044.83% derbyall 022 0 191.76% compatibility 022 0 .% demoSuite sol NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite solN+1 01138911389 0 478.07% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0226226 067.25% derbyall 022 0 260.33% compatibility 022 0 .% demoSuite sparc 01138911389 0 653.11% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0226226 047.66% derbyall 022 0 234.32% compatibility 022 0 .% demoSuite vista NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite vista-64 01138311383 0 222.83% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0226226 057.18% derbyall NA NA NANA compatibility 022 0 .% demoSuite w2003 01138311383 0 287.81% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0226226 068.66% derbyall F:2,E:020 0 0.13% compatibility 022 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-792201.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/792201_bySig.html *Jvm: 1.5* lin 0227227 052.99% derbyall 095999599 0 1684.79% suitesAll sles 0227227 047.86% derbyall 095999599 0 1059.44% suitesAll sol NA NA NANA derbyall NA NA NANA suitesAll solN+1 0227227 061.31% derbyall 095999599 0 1411.85% suitesAll sparc 0227227 048.16% derbyall 095999599 0 1222.39% suitesAll vista 1227226 044.20% derbyall 095939593 0 885.45% suitesAll vista-64 0227227 058.26% derbyall 095939593 0 209.84% suitesAll w2003 0227227 053.90% derbyall 095939593 0 555.68% suitesAll Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-792201.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/FailReports/792201_bySig.html *Jvm: 1.4* lin 0224224 253.35% derbyall 094469446 0 1525.24% suitesAll sles 0224224
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (17 issues) Subscriber: derby-dev Key Summary DERBY-712 Support for sequences https://issues.apache.org/jira/browse/DERBY-712 DERBY-4165 Document the effect of shutdown on in progress transactions and open connections. https://issues.apache.org/jira/browse/DERBY-4165 DERBY-4034 Document database name and attribute length and character set limitations for network client https://issues.apache.org/jira/browse/DERBY-4034 DERBY-1209 It would be good to add an example to the SYSCS_UTIL.SYSCS_CHECK_TABLE documentation for how to check all tables https://issues.apache.org/jira/browse/DERBY-1209 DERBY-4208 Parameters ? with OFFSET and/or FETCH https://issues.apache.org/jira/browse/DERBY-4208 DERBY-4263 PropertySetter isn't able to recognize JDK without version number in path https://issues.apache.org/jira/browse/DERBY-4263 DERBY-1923 XML operators - Xalan requirement https://issues.apache.org/jira/browse/DERBY-1923 DERBY-4217 Make the default port for the suites.All run configurable with a system property. https://issues.apache.org/jira/browse/DERBY-4217 DERBY-4081 BTreeController.comparePreviousRecord() may fail to release latch on left-most leaf https://issues.apache.org/jira/browse/DERBY-4081 DERBY-4137 OOM issue using XA with timeouts https://issues.apache.org/jira/browse/DERBY-4137 DERBY-4102 Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K https://issues.apache.org/jira/browse/DERBY-4102 DERBY-3788 Provide a zero-admin way of updating the statisitcs of an index https://issues.apache.org/jira/browse/DERBY-3788 DERBY-2895 convert lang/declareGlobalTempTableJavaJDBC30.java to JUnit https://issues.apache.org/jira/browse/DERBY-2895 DERBY-4293 Mutable public static variables https://issues.apache.org/jira/browse/DERBY-4293 DERBY-4241 Improve transition from read-only to writable Clob representation https://issues.apache.org/jira/browse/DERBY-4241 DERBY-3473 write test cases to test locking during tree operation https://issues.apache.org/jira/browse/DERBY-3473 DERBY-3986 Stop dropping build artifacts in the subversion-controlled source tree https://issues.apache.org/jira/browse/DERBY-3986 You may edit this subscription at: https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?subId=10396&filterId=12310751
[jira] Updated: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[
https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-4053:
---
Attachment: DERBY4053_patch1_diff_July092009.txt
This patch DERBY4053_patch1_diff_July092009.txt is not yet intended for
checkin.
I thought this patch should fix the XA cleanup issue where we were not
differentiating between global XA vs local XA transaction and hence not roling
back local XA transaction before trying to close the connection.
Unless my code changes are wrong, it appears though that all the XA tests in
jdbc4 suite are non-global XA transactions. Is that right? The reason I ask is,
I had printlns in all the implementations of the new method
isInGlobalTransaction and they all always return false. I was expecting
following method in EmbedXAConnection.java to return true sometimes because we
are dealing with global XA transaction.
Index: java/engine/org/apache/derby/jdbc/EmbedXAConnection.java
===
--- java/engine/org/apache/derby/jdbc/EmbedXAConnection.java(revision 792143
)
+++ java/engine/org/apache/derby/jdbc/EmbedXAConnection.java(working copy)
@@ -22,6 +22,7 @@
package org.apache.derby.jdbc;
import org.apache.derby.impl.jdbc.Util;
+import org.apache.derby.iapi.jdbc.BrokeredConnectionControl;
import org.apache.derby.iapi.jdbc.EngineConnection;
import org.apache.derby.iapi.jdbc.ResourceAdapter;
@@ -53,6 +54,11 @@
xaRes = new EmbedXAResource (this, ra);
}
+/** @see BrokeredConnectionControl#isInGlobalTransaction() */
+public boolean isInGlobalTransaction() {
+ return isGlobal();
+}
+
/**
* Check if this connection is part of a global XA transaction.
*
Can someone review this patch for me? There are not many comments yet. I will
put those soon.
I am right now also trying to work on a standalone repro case which will
reproduce our theory of local XA transaction not getting rolled back before
connection.close and hence the server shutdown does not happen correctly
causing next server start to hang.
> suites.All hang with message java.net.BindException: Address already in use:
> NET_Bind in derby.log
> ---
>
> Key: DERBY-4053
> URL: https://issues.apache.org/jira/browse/DERBY-4053
> Project: Derby
> Issue Type: Bug
> Components: Network Server, Test
>Affects Versions: 10.5.1.1
>Reporter: Kathey Marsden
> Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log,
> DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt,
> javacore.20090211.123031.4000.0001.txt, suites.All.out
>
>
> Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang
> in the test run. The last test to run successfully was
> xtestNestedSavepoints, but I am not sure exactly what test caused the hang.
> I took a thread dump which I will attach, which showed network server up and
> running but no ClientThread and a ping attempt blocked.
> This hang is very similar to the hang that was seen after the fix attempts
> for DERBY-1465 but that change was backed out so it is not related to that
> change. It could be that the change for DERBY-1465 just made this highly
> intermittent problem more likely.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Hi Dag, We are also adding support for this via a JDBC ESCAPE in JDBC 4.1 The current versions of Sybase support TOP and SQL Anywhere and MS SQL Server supports it as well INFORMIX IDS supports Limit Regards lance On Jul 9, 2009, at 10:06 AM, Dag H. Wanvik wrote: Kathey Marsden writes: I am hesitant to introduce behavior that is not standard compliant, but may be less hesitant if it is a sort of implied industry standard. What other database products do/do not support this syntax? * MySQL allows it in their LIMIT construct, cf. http://dev.mysql.com/doc/refman/5.0/en/select.html * DB2 has a syntax similar to the standard, but doesn't appear to allow dynamic parameters: http://bytes.com/groups/ibm-db2/185741-jdbc-fetch-first-rows-only http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0005280.htm * PostGreSQL has both a LIMIT and the new OFFSET/FETCH FIRST syntax: http://www.postgresql.org/docs/current/static/sql-select.html It appears to allow dynamic evaluation, c.f this quote: "If the count expression evaluates to NULL, it is treated as LIMIT ALL, i.e., no limit. If start evaluates to NULL, it is treated the same as OFFSET 0." in other words it can be an expression, not just a literal as the standard currently requires. * Sybase has a special statement called SET ROWCOUNT, it seems. It's not equivalent, I think, since "A limit violation occurs when the number of rows returned by a select statement exceeds the limit value", says the documentation: http://infocenter.sybase.com/help/topic/com.sybase.help.ase_15.0.sag2/html/sag2/sag234.htm but presumably this can be set before each execution of SELECT, although the docs are not explicit about this, at least not in the cited section. * SQL Server has a similar statement to Sybase, but the semantics seem more benign: "Causes SQL Server to stop processing the query after the specified number of rows are returned." (no talk of violation or error here). http://msdn.microsoft.com/en-us/library/ms188774.aspx Looking at this example, it seems work dynamically: http://authors.aspalliance.com/stevesmith/articles/sprowcount.asp * Oracle has a ROWNUM builtin that can be used in dynamic queries, akin to the standard ROW_NUMBER(). This can be used for DERBY also, but the current implementation of ROW_NUMBER has some bugs and users seems to balk at the WINDOWing complexity for something as simple as limiting the number of rows returned. Significantly, it still doesn't work in conjunction with ORDER BY (DERBY-3634). Note that the Oracle version requires a subquery, but does not require a windowing syntax: select * from ( select * from emp order by sal desc ) where ROWNUM <= 5; http://www.oracle.com/technology/oramag/oracle/06-sep/o56asktom.html In summary, the record is a bit mixed. Hearsay from the SQL committee indicates that the 2011 version will allow dynamic parameters for OFFSET/FETCH NEXT, and it seem the PostGreSQL people have had similar thoughts. Thanks, Dag
Re: Question regarding DERBY-4208 Parameters ? with OFFSET and/or FETCH
Kathey Marsden writes: > I am hesitant to introduce behavior that is not standard compliant, > but may be less hesitant if it is a sort of implied industry standard. > What other database products do/do not support this syntax? * MySQL allows it in their LIMIT construct, cf. http://dev.mysql.com/doc/refman/5.0/en/select.html * DB2 has a syntax similar to the standard, but doesn't appear to allow dynamic parameters: http://bytes.com/groups/ibm-db2/185741-jdbc-fetch-first-rows-only http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0005280.htm * PostGreSQL has both a LIMIT and the new OFFSET/FETCH FIRST syntax: http://www.postgresql.org/docs/current/static/sql-select.html It appears to allow dynamic evaluation, c.f this quote: "If the count expression evaluates to NULL, it is treated as LIMIT ALL, i.e., no limit. If start evaluates to NULL, it is treated the same as OFFSET 0." in other words it can be an expression, not just a literal as the standard currently requires. * Sybase has a special statement called SET ROWCOUNT, it seems. It's not equivalent, I think, since "A limit violation occurs when the number of rows returned by a select statement exceeds the limit value", says the documentation: http://infocenter.sybase.com/help/topic/com.sybase.help.ase_15.0.sag2/html/sag2/sag234.htm but presumably this can be set before each execution of SELECT, although the docs are not explicit about this, at least not in the cited section. * SQL Server has a similar statement to Sybase, but the semantics seem more benign: "Causes SQL Server to stop processing the query after the specified number of rows are returned." (no talk of violation or error here). http://msdn.microsoft.com/en-us/library/ms188774.aspx Looking at this example, it seems work dynamically: http://authors.aspalliance.com/stevesmith/articles/sprowcount.asp * Oracle has a ROWNUM builtin that can be used in dynamic queries, akin to the standard ROW_NUMBER(). This can be used for DERBY also, but the current implementation of ROW_NUMBER has some bugs and users seems to balk at the WINDOWing complexity for something as simple as limiting the number of rows returned. Significantly, it still doesn't work in conjunction with ORDER BY (DERBY-3634). Note that the Oracle version requires a subquery, but does not require a windowing syntax: select * from ( select * from emp order by sal desc ) where ROWNUM <= 5; http://www.oracle.com/technology/oramag/oracle/06-sep/o56asktom.html In summary, the record is a bit mixed. Hearsay from the SQL committee indicates that the 2011 version will allow dynamic parameters for OFFSET/FETCH NEXT, and it seem the PostGreSQL people have had similar thoughts. Thanks, Dag
Re: 10.5.2 release update
Kathey, yes, I will work on DERBY-4053. In few minutes, I will post a patch that I thought should fix the XA issue where we were not differentiating between global XA vs local XA transaction. Despite the change, I still get the hang. I will post the patch to jira soon and then will try to work on a standalone repro case which will reproduce our theory of local XA transaction not getting rolled back before connection.close and possibly causing problems with network server close. thanks, Mamta On Wed, Jul 8, 2009 at 11:22 AM, Kathey Marsden wrote: > I am still marching to the current posted schedule for the 10.5.2 release > http://wiki.apache.org/db-derby/DerbyTenFiveTwoRelease.  Fixes that you want > in the release need to be checked in by 9am PDT, Tuesday July 14.  Please > mark issues with Urgency *Urgent* if you plan to check into the 10.5 branch >  by that time. > > I have marked two issues as Blocker urgency: DERBY-4245  which just needs > backport and DERBY-4053 for which I think we have a good idea for a fix and > is worth waiting on.  Mamta are you willing to pick up DERBY-4053? > > There are 7 Urgent issues for which I would consider delaying a few days if > needed.  Some I have little hope will make it but they are still there. >  Please let me know if something should be added. > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&resolution=-1&customfield_12310050=Urgent&sorter/field=issuekey&sorter/order=DESC > > Thank you all for triaging bugs.  I think we are converging a on a good > system for community bug review. Thanks Dag for coordinating.  There are > still a couple unclaimed blocks of bugs available at: > http://wiki.apache.org/db-derby/DerbyTenFiveTwoBugTriage > > It looks like  a good release with 42 fixes so far: > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=12313870&resolution=1&sorter/field=issuekey&sorter/order=DESC > Friday I plan to submit draft release notes if I don't have too many battles > with the release note tool. > > Thanks > > Kathey > >
[jira] Resolved: (DERBY-4240) An index cause SQL ORDER BY can't return correct result
[ https://issues.apache.org/jira/browse/DERBY-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-4240. Resolution: Duplicate duplicate of DERBY-3926. > An index cause SQL ORDER BY can't return correct result > --- > > Key: DERBY-4240 > URL: https://issues.apache.org/jira/browse/DERBY-4240 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.2.0 >Reporter: Simon Meng >Assignee: Mamta A. Satoor > > Following snippet is a SQL example program. It can reproduce a database > issue. > DROP TABLE test1; > DROP TABLE test2; > CREATE TABLE test1 (id BIGINT NOT NULL, name VARCHAR(255), PRIMARY KEY (id)); > CREATE TABLE test2 (entity_id BIGINT, rel_id BIGINT); > CREATE INDEX idx_test2 ON test2 (entity_id); > INSERT INTO test1 (id, name) VALUES (102, 'Tom'); > INSERT INTO test1 (id, name) VALUES (1, null); > INSERT INTO test1 (id, name) VALUES (103, 'Jerry'); > INSERT INTO test1 (id, name) VALUES (101, 'Pupy'); > INSERT INTO test2 (entity_id, rel_id) VALUES (1, 102); > INSERT INTO test2 (entity_id, rel_id) VALUES (1, 101); > INSERT INTO test2 (entity_id, rel_id) VALUES (1, 103); > SELECT t1.id, t1.name FROM test2 t2 INNER JOIN test1 t1 ON t2.rel_id = t1.id > WHERE t2.entity_id = 1 ORDER BY t1.id ASC; > The expected result should be > ID NAME > -- > 101Pupy > 102Tom > 103Jerry > When running the program, I got below result. > ID NAME > -- > 102Tom > 101Pupy > 103Jerry > The result is obviously wrong. Using ORDER BY ASC does not get expected > result. I found ORDER BY DESC works fine. > Note: there is an index (idx_test2). This index affects the SQL query. If the > index is dropped, ORDER BY ASC can return correct result.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-4240) An index cause SQL ORDER BY can't return correct result
[ https://issues.apache.org/jira/browse/DERBY-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor closed DERBY-4240. -- > An index cause SQL ORDER BY can't return correct result > --- > > Key: DERBY-4240 > URL: https://issues.apache.org/jira/browse/DERBY-4240 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.2.0 >Reporter: Simon Meng >Assignee: Mamta A. Satoor > > Following snippet is a SQL example program. It can reproduce a database > issue. > DROP TABLE test1; > DROP TABLE test2; > CREATE TABLE test1 (id BIGINT NOT NULL, name VARCHAR(255), PRIMARY KEY (id)); > CREATE TABLE test2 (entity_id BIGINT, rel_id BIGINT); > CREATE INDEX idx_test2 ON test2 (entity_id); > INSERT INTO test1 (id, name) VALUES (102, 'Tom'); > INSERT INTO test1 (id, name) VALUES (1, null); > INSERT INTO test1 (id, name) VALUES (103, 'Jerry'); > INSERT INTO test1 (id, name) VALUES (101, 'Pupy'); > INSERT INTO test2 (entity_id, rel_id) VALUES (1, 102); > INSERT INTO test2 (entity_id, rel_id) VALUES (1, 101); > INSERT INTO test2 (entity_id, rel_id) VALUES (1, 103); > SELECT t1.id, t1.name FROM test2 t2 INNER JOIN test1 t1 ON t2.rel_id = t1.id > WHERE t2.entity_id = 1 ORDER BY t1.id ASC; > The expected result should be > ID NAME > -- > 101Pupy > 102Tom > 103Jerry > When running the program, I got below result. > ID NAME > -- > 102Tom > 101Pupy > 103Jerry > The result is obviously wrong. Using ORDER BY ASC does not get expected > result. I found ORDER BY DESC works fine. > Note: there is an index (idx_test2). This index affects the SQL query. If the > index is dropped, ORDER BY ASC can return correct result.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1528) Preparing "INSERT INTO table SELECT FROM (...)" may cause NullPointerException and subsequent internal errors reported by RawStore module
[ https://issues.apache.org/jira/browse/DERBY-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1528: -- Issue & fix info: [High Value Fix, Repro attached] (was: [High Value Fix]) Urgency: Normal Triaged for 10.5.2. > Preparing "INSERT INTO table SELECT FROM (...)" may cause > NullPointerException and subsequent internal errors reported by RawStore > module > - > > Key: DERBY-1528 > URL: https://issues.apache.org/jira/browse/DERBY-1528 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.1.3.1 >Reporter: Knut Anders Hatlen > Attachments: repro1528_assert.java, repro1528_npe.java > > > When preparing a "INSERT INTO table SELECT FROM (...)" statement, > Derby in some cases throw a NullPointerException or an > AssertFailure. This happens when a '?' occurs in a VALUES statement in > the from list. If one tries to access the table after the > NullPointerException, this exception is thrown: > ERROR 40XT0: An internal error was identified by RawStore module. > Example: > ij> create table t (text varchar(20), len int); > 0 rows inserted/updated/deleted > ij> prepare p as 'insert into t select x, length(x) from (values(?)) as v(x)'; > ERROR XJ001: Java exception: ': java.lang.NullPointerException'. > ij> select * from t; > ERROR 40XT0: An internal error was identified by RawStore module. > Replacing '?' with 'CAST (? AS VARCHAR(20))' fixes the problem, but > there is enough information in the query to determine the type of the > parameter even without the cast. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1595) Network server fails with DRDAProtocolException if a BLOB with size 2147483647 is streamed from client
[ https://issues.apache.org/jira/browse/DERBY-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1595: -- Urgency: Normal Triaged for 10.5.2. > Network server fails with DRDAProtocolException if a BLOB with size > 2147483647 is streamed from client > -- > > Key: DERBY-1595 > URL: https://issues.apache.org/jira/browse/DERBY-1595 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.2.1.6 >Reporter: Andreas Korneliussen >Priority: Minor > > When executing a program which inserts a BLOB of size 2GB-1, the Network > server fails with DRDAProtocolException. This happens before it starts > handling the actual LOB data: > java org.apache.derby.drda.NetworkServerControl start > Apache Derby Network Server - 10.2.0.4 alpha started and ready to accept > connections on port 1527 at 2006-07-26 14:15:21.284 GMT > Execution failed because of a Distributed Protocol Error: > DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = c > org.apache.derby.impl.drda.DRDAProtocolException > at > org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:441) > at > org.apache.derby.impl.drda.DDMReader.readLengthAndCodePoint(DDMReader.java:554) > at > org.apache.derby.impl.drda.DDMReader.getCodePoint(DDMReader.java:617) > at > org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(DRDAConnThread.java:4072) > at > org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA(DRDAConnThread.java:3928) > at > org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:3806) > at > org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:3640) > at > org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:928) > at > org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:254) > null > org.apache.derby.impl.drda.DRDAProtocolException > at > org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:441) > at > org.apache.derby.impl.drda.DDMReader.readLengthAndCodePoint(DDMReader.java:554) > at > org.apache.derby.impl.drda.DDMReader.getCodePoint(DDMReader.java:617) > at > org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(DRDAConnThread.java:4072) > at > org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA(DRDAConnThread.java:3928) > at > org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:3806) > at > org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:3640) > at > org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:928) > at > org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:254) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1599) Clob.getSubString() throws NullPointerException when created by updatable result set
[ https://issues.apache.org/jira/browse/DERBY-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1599: -- Issue & fix info: [High Value Fix, Repro attached] (was: [High Value Fix]) Urgency: Normal Triaged for 10.5.2. > Clob.getSubString() throws NullPointerException when created by updatable > result set > > > Key: DERBY-1599 > URL: https://issues.apache.org/jira/browse/DERBY-1599 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.1.3.1, 10.2.1.6 >Reporter: Knut Anders Hatlen >Priority: Minor > Attachments: Repro.java > > > If you create a clob value with one of the ResultSet.updateXXX methods that > take a stream or a reader, and retrieve that value with ResultSet.getClob(), > a NullPointerException will be thrown when getSubString() is called on the > returned Clob object. This happens with the network client driver, and it has > been observed on Derby 10.1.3.1 and trunk. > Exception in thread "main" java.lang.NullPointerException > at org.apache.derby.client.am.Clob.getSubStringX(Clob.java:229) > at org.apache.derby.client.am.Clob.getSubString(Clob.java:210) > at Repro.main(Repro.java:24) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1632) During revoke privilege, Derby does not look for replacement privilege for the dependent objects and simply drops the dependent objects. This is not SQL compliant and shou
[ https://issues.apache.org/jira/browse/DERBY-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1632: -- Issue & fix info: [Repro attached] Urgency: Normal Triaged for 10.5.2. > During revoke privilege, Derby does not look for replacement privilege for > the dependent objects and simply drops the dependent objects. This is not SQL > compliant and should be fixed. > --- > > Key: DERBY-1632 > URL: https://issues.apache.org/jira/browse/DERBY-1632 > Project: Derby > Issue Type: Bug > Components: Documentation, SQL >Affects Versions: 10.2.1.6 >Reporter: Mamta A. Satoor > > Currently, when an object (trigger/constraint/view) is created, it depends on > the available required privilege at the user level. If none found, it depends > on the available required privilege at PUBLIC level. If none exist both at > user level or PUBLIC level, then create object fails. > To reiterate, if the privilege is found say at the user level, the object > depends on that privilege. Consider the case, where the privilege also exist > at the PUBLIC level. Later, when a revoke privilege is issued at the user > level, the dependent object gets a revoke invalidation action and the > dependent object drops itself. Instead, the dependent object should make > itself depend on the PUBLIC level privilege. This does not happen in Derby at > this point and this behavior is not SQL compliant and should be fixed. > eg for the problem at hand > user1 > create table t1 > grant select on t1 to user2, public > user2 > create view v1 as select * from user1.t1 > -- this view will depend on the user level select privilege on table t1 > user1 > revoke select on t1 from user2 > -- this revoke will end up dropping the view. The view could have made itself > depend on the PUBLIC level select privilege > -- on t1 but that doesn't happen currently > another eg for the same problem > user1 > create table t1 > grant select on t1 to public > user2 > create view v1 as select * from user1.t1 > -- this view will depend on the PUBLIC level select privilege on table t1 > user1 > grant select on to to user2 > revoke select on t1 from public > -- this revoke ends up dropping the view user2.v1 eventhough there is a user > level SELECT privilege availble > -- on user1.t1 > So, in brief, the problem is that when a dependent object gets a revoke > invalidation action, it does not check if there is another privilege > available to replace the privilege being revoked. Instead, they just go ahead > and drop themselves. > Until we fix this behavior, we should document it so the user will know what > to expect for same privilege being available at different levels. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1650) derbytools.jar needs org.apache.derby.iapi.reference.Attribute even though that class contains only interface Strings
[
https://issues.apache.org/jira/browse/DERBY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-1650:
--
Triaged for 10.5.2.
I believe the dependency comes from this code in impl/tools/ij/URLCheck:
Class att = Attribute.class;
//Use reflection to get the list of valid keys from the
Attribute class.
//The Attribute class is an interface and therefore all the
field
//for it are public.
Field[] fields = att.getFields();
for (int i = 0; i < fields.length; i++)
{
Field aField = (Field)fields[i];
props.addElement(aField.get(att));
}
> derbytools.jar needs org.apache.derby.iapi.reference.Attribute even though
> that class contains only interface Strings
> -
>
> Key: DERBY-1650
> URL: https://issues.apache.org/jira/browse/DERBY-1650
> Project: Derby
> Issue Type: Bug
> Components: Tools
>Affects Versions: 10.2.1.6
>Reporter: Andrew McIntyre
>
> A recent checkin to remove the reference to
> org.apache.derby.iapi.reference.Attribute in the derbytools.jar build caused
> numerous tests to fail. This class contains only Strings from an interface,
> so the compiler should compile out all references to this class. The reason
> for needing this class at runtime should be tracked down and fixed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1666) Show Views and Show Synonyms has confusing column names in results
[ https://issues.apache.org/jira/browse/DERBY-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1666: -- Issue & fix info: [Known fix, Newcomer, Repro attached] Urgency: Normal Issue Type: Improvement (was: Bug) Triaged for 10.5.2. Reclassifying from bug to improvement. > Show Views and Show Synonyms has confusing column names in results > -- > > Key: DERBY-1666 > URL: https://issues.apache.org/jira/browse/DERBY-1666 > Project: Derby > Issue Type: Improvement > Components: Tools >Affects Versions: 10.2.1.6 >Reporter: David Van Couvering >Priority: Minor > > When you run SHOW VIEWS and SHOW SYNONYMS, the column names are confusing. > They use TABLE_SCHEM and TABLE_NAME instead of VIEW_SCHEM/VIEW_NAME and > SYNONYM_SCHEM/SYONYM_NAME > === Examples === > ij> show views; > TABLE_SCHEM |TABLE_NAME |REMARKS > > APP |AA_FLIGHTS | > ij> show synonyms; > TABLE_SCHEM |TABLE_NAME|REMARKS > > APP |COLUMNS | > APP |TRIGGERS | -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset
[
https://issues.apache.org/jira/browse/DERBY-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-1696:
--
Issue & fix info: [Repro attached]
Triaged for 10.5.2.
> transaction may sometimes keep lock on a row after moving off the resultset
> in scrollable updatable resultset
> -
>
> Key: DERBY-1696
> URL: https://issues.apache.org/jira/browse/DERBY-1696
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
>Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4
>Reporter: Andreas Korneliussen
> Attachments: DERBY-1696.diff, DERBY-1696.stat, DERBY-1696v2.diff
>
>
> If an application does the following:
> Statement s = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
> ResultSet.CONCUR_UPDATABLE);
> ResultSet rs = s.executeQuery("select * from t1");
> rs.afterLast();
> rs.last();
> rs.next();
> After doing this in transaction isolation level
> read-committed/read-uncommitted, the last row is still locked with an update
> lock.
> This is detected by running the JUnit testcase
> ConcurrencyTest.testUpdatePurgedTuple1 in the DerbyNetClient framework.
> (NOTE: the bug is revealed by this test, because the network server does a
> rs.last() as the first operation on a scrollable updatable resultset to count
> number of rows)
> What triggers this bug, seems to be the repositioning of the cursor after the
> underlying all records have been inserted into the hashtable from the source
> scan. When moving off the result set (to afterLast() or beforeFirst()) no
> action is done to release the lock of the current row.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4292) creation of FileInputStream in org.apache.derby.impl.tools.ij.Main not wrapped in privilege block which can cause problems running under SecurityManager
[
https://issues.apache.org/jira/browse/DERBY-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tiago R. Espinha updated DERBY-4292:
Attachment: DERBY-4292-ReproTest.patch
I'm attaching the latest patch to this issue.
Kathey said:
> "...and add a test if the file does not exist..."
Is this really necessary? If the file does not exist in the Derby code tree,
the SupportFilesSetup will blow up on its own, and if it does exist there, then
it is safe to say that it will exist in the extinout folder.
If anything, I think we can later on change that ij behavior and make it throw
an exception rather than an error message, so that the test fails when the file
does not exist.
What I'm thinking is that by putting such check on a test, we sort of are
masking the problem with ij exiting with status 0 even when the file does not
exist. If you think we should have that check anyway, I can easily do it with a
new File().exists().
For this patch (just the Repro test) I removed the SecurityManager decorator
and added the header to the sql file. The fix remains the same.
I'll be running regressions today.
> creation of FileInputStream in org.apache.derby.impl.tools.ij.Main not
> wrapped in privilege block which can cause problems running under
> SecurityManager
> -
>
> Key: DERBY-4292
> URL: https://issues.apache.org/jira/browse/DERBY-4292
> Project: Derby
> Issue Type: Bug
> Components: Tools
>Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.2.0, 10.5.1.1,
> 10.6.0.0
>Reporter: Kathey Marsden
>Assignee: Tiago R. Espinha
> Attachments: DERBY-4292-Fix.patch, DERBY-4292-Fix.patch,
> DERBY-4292-Fix.patch, DERBY-4292-ReproTest.patch, DERBY-4292-ReproTest.patch,
> DERBY-4292-ReproTest.patch, derby4292.zip, derby4292.zip, run.out.debugall
>
>
> org.apache.derby.impl.tools.ij.Main has this code where the call to
> FileInputStream is not wrapped in a privilege block:
>try {
> in1 = new FileInputStream(file);
> if (in1 != null) {
> in1 = new BufferedInputStream(in1,
> utilMain.BUFFEREDFILESIZE);
> in = langUtil.getNewInput(in1);
> }
> } catch (FileNotFoundException e) {
> if (Boolean.getBoolean("ij.searchClassPath")) {
> in =
> langUtil.getNewInput(util.getResourceAsStream(file));
> }
> This can cause issues when running under SecurityManager
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1735) Large number of rows in a VALUES clause (e.g. for an INSERT) can result in a StackOverflowError
[ https://issues.apache.org/jira/browse/DERBY-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1735: -- Issue & fix info: [Repro attached] Urgency: Normal Triaged for 10.5.2. > Large number of rows in a VALUES clause (e.g. for an INSERT) can result in a > StackOverflowError > --- > > Key: DERBY-1735 > URL: https://issues.apache.org/jira/browse/DERBY-1735 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6, 10.3.1.4 >Reporter: Daniel John Debrunner >Priority: Minor > > With DERBY-766 / DERBY-1714extending the limit for number of rows in a VALUES > clause the next error seen is a stack overflow. > issue can be seen by increasing the number of rows in the testInsertValues > portion of largeCodeGen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3669) ClientXADataSource fetched from JNDI not identical as originally bound; some properties have String "null" instead of null
[
https://issues.apache.org/jira/browse/DERBY-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3669:
--
Affects Version/s: 10.5.1.1
Fix Version/s: 10.5.1.2
Merged fix to 10.5.
Committed revision 792491.
> ClientXADataSource fetched from JNDI not identical as originally bound; some
> properties have String "null" instead of null
> --
>
> Key: DERBY-3669
> URL: https://issues.apache.org/jira/browse/DERBY-3669
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.5.1.1, 10.6.0.0
>Reporter: Myrna van Lunteren
>Assignee: Knut Anders Hatlen
>Priority: Minor
> Fix For: 10.5.1.2, 10.6.0.0
>
> Attachments: d3669-1a.diff
>
>
> Running the test XAJNDITest (from old xaJNDI.java) with network server fails
> because the XADataSource as bound to JNDI, and then fetch from JNDI are not
> identical.
> This is what the test does to get the XADataSource & to bind & get it from
> JNDI:
>
> ...
> XADataSource xads = J2EEDataSource.getXADataSource();
> String dbName =
> TestConfiguration.getCurrent().getDefaultDatabaseName();
> JDBCDataSource.setBeanProperty(xads, "databaseName", dbName);
> JDBCDataSource.setBeanProperty(xads, "createDatabase", "create");
> JDBCDataSource.setBeanProperty(xads, "description", "XA
> DataSource");
> Hashtable env = new Hashtable();
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> // using a system property - these will have to be passed in
> somehow.
> env.put(Context.PROVIDER_URL, "ldap://"; + ldapServer + ":" +
> ldapPort);
> env.put(Context.SECURITY_AUTHENTICATION, "simple");
> ic.rebind("cn=compareDS, o=" + dnString, xads);
> javax.sql.XADataSource ads =
> (javax.sql.XADataSource)ic.lookup("cn=compareDS, o=" +
> dnString);
> ...
> ---
> Further checking showed that the fetched datasource has a String with value
> "null" rather than a null value for the following properties:
> dataSourceName, connectionAttributes, traceDirectory, traceFile.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1740) Change error message to indicate encryptionkey length to be atleast 16 characters instead of 8 characters
[ https://issues.apache.org/jira/browse/DERBY-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1740: -- Issue & fix info: [Repro attached] Urgency: Normal Triaged for 10.5.2. > Change error message to indicate encryptionkey length to be atleast 16 > characters instead of 8 characters > - > > Key: DERBY-1740 > URL: https://issues.apache.org/jira/browse/DERBY-1740 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.0.2.0 > Environment: Any >Reporter: Rajesh Kartha >Priority: Minor > Attachments: derby-1740-1a.diff > > > While attempting to create a encrypted database with even key length of 14 > characters, it fails with the error message indicating the key length should > be atleast 8 characters. > -- > -- Attempt to encrypt using key of lenght 14 > -- > ij> connect > 'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=11223344556677'; > ERROR XJ041: Failed to create database 'adb', see the next exception for > details. > ERROR XBM01: Startup failed due to an exception. See next exception for > details. > ERROR XBCX2: Initializing cipher with a boot password that is too short. The > password must be at least 8 characters long. > -- > --Requires 16 characters for the encryptionKey > -- > ij> connect > 'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=1122334455667788'; > ij> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1742) SYSTEMALIAS column of type BOOLEAN in SYS.SYSALIASES is created with the incorrect maximun length of 0
[ https://issues.apache.org/jira/browse/DERBY-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1742: -- Urgency: Normal Issue Type: Task (was: Bug) Triaged for 10.5.2. Description says that it is an investigation, so changing issue type from Bug to Task. > SYSTEMALIAS column of type BOOLEAN in SYS.SYSALIASES is created with the > incorrect maximun length of 0 > -- > > Key: DERBY-1742 > URL: https://issues.apache.org/jira/browse/DERBY-1742 > Project: Derby > Issue Type: Task > Components: SQL >Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1 >Reporter: Daniel John Debrunner >Priority: Trivial > > Boolean type's correct maximum width is 1. > Seen by the COLUMN_SIZE column from DatabaseMetaData.getColumns returning 0 > instead of 1. > Caused by passing a 0 instead of a 1 in SYSAliasesRowFactory, will be fixed > by DERBY-1734, which stops > code like this passing in information that is redundant (and hence a chance > for it to be wrong). > Don't believe ir has any affect on the runtime behaviour of the system, > adding this issue to investigate if an upgrade fix is required > or just leave it at the wrong value for old databases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1745) System catalog columns of type BIGINT and INT created with incorrect precision of zero.
[ https://issues.apache.org/jira/browse/DERBY-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1745: -- Urgency: Normal Issue Type: Task (was: Bug) Triaged for 10.5.2. The bug description says "This bug is here to investigate upgrade issues and fix them if required." Changing issue type from Bug to Task. > System catalog columns of type BIGINT and INT created with incorrect > precision of zero. > --- > > Key: DERBY-1745 > URL: https://issues.apache.org/jira/browse/DERBY-1745 > Project: Derby > Issue Type: Task > Components: SQL >Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, > 10.2.1.6 >Reporter: Daniel John Debrunner >Priority: Minor > > Due to the way system column metadata was handled in the code system columns > of these types are always created with precision 0. > User defined columns of these types will have precision 10 (INT) and 19 > (BIGINT) > DERBY-1734 will fix this for 10.3 and hopefully 10.2 by a merge before the > release. > This bug is here to investigate upgrade issues and fix them if required. > Not known of any incorrect issues due to this, except for incorrect JDBC > metadata for such columns. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-1762) Setting the derby.locks.waitTimeout as a system property using System.setProperty does not affect booted databases
[ https://issues.apache.org/jira/browse/DERBY-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen resolved DERBY-1762. --- Resolution: Invalid Triaged for 10.5.2. I believe the described behaviour is in accordance with the documentation, so I'm closing this bug as invalid. Here are the relevant sections from the manuals: Reference manual, Dynamic and static properties - http://db.apache.org/derby/docs/10.5/ref/crefproperdynstat.html: > Only properties set in the following ways have the potential to be dynamic: > > * As database-wide properties > * As system-wide properties via a Properties object in the > application in which the Derby engine is embedded Following from the above, since it's set as a system-wide property in this scenario, it needs to follow the rules described in Reference manual, Changing the system-wide properties programmatically, Using a Properties object within an application or statement - http://db.apache.org/derby/docs/10.5/devguide/cdevsetprop11561.html#cdevsetprop11561__propobj: > In embedded mode, your application runs in the same JVM as Derby, so > you can also set system properties within an application using a > Properties object before loading the Derby JDBC driver. Since the Derby JDBC driver has already been loaded in the scenario described in this bug report, changing a system property is not guaranteed to have any effect. > Setting the derby.locks.waitTimeout as a system property using > System.setProperty does not affect booted databases > -- > > Key: DERBY-1762 > URL: https://issues.apache.org/jira/browse/DERBY-1762 > Project: Derby > Issue Type: Bug > Components: Documentation, Services >Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, > 10.2.1.6, 10.3.1.4 >Reporter: Daniel John Debrunner >Priority: Minor > > Tuning guide for derby.locks.waitTimeout states it is a dynamic property, but > when set as a system property using System.setProperty it does not change the > timeout for any databases already booted. It might change it for databases > that are booted after the change, I didn't test that. > If the property is set as a database property then it is dynamic, taking > effect immediately. > Guess it affects all versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1773) insertRow() and updateRow() fail with syntax error when column has an alias
[ https://issues.apache.org/jira/browse/DERBY-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1773: -- Issue & fix info: [Repro attached] Urgency: Normal Triaged for 10.5.2. > insertRow() and updateRow() fail with syntax error when column has an alias > --- > > Key: DERBY-1773 > URL: https://issues.apache.org/jira/browse/DERBY-1773 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Knut Anders Hatlen >Priority: Minor > Attachments: Alias.java > > > When the select query used in an updatable result set has column aliases, a > syntax error is thrown when executing ResultSet.insertRow() and > ResultSet.updateRow(). The problem is seen on embedded and client. Repro is > attached. > Exception in thread "main" ERROR 42X14: 'A1' is not a column in table or VTI > 'APP.T'. > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:316) > at > org.apache.derby.impl.sql.compile.ResultColumn.bindResultColumnByName(ResultColumn.java:677) > at > org.apache.derby.impl.sql.compile.ResultColumnList.bindResultColumnsByName(ResultColumnList.java:682) > at > org.apache.derby.impl.sql.compile.ResultSetNode.bindResultColumns(ResultSetNode.java:683) > at > org.apache.derby.impl.sql.compile.SelectNode.bindResultColumns(SelectNode.java:742) > at > org.apache.derby.impl.sql.compile.UpdateNode.bind(UpdateNode.java:349) > at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:345) > at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:111) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:723) > at > org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3734) > at Alias.main(Alias.java:15) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1782) When a privilege is revoked at table level, Derby should only drop objects that require that particular privilege and not all the objects that require some form of privile
[ https://issues.apache.org/jira/browse/DERBY-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1782: -- Attachment: repro.sql I wrapped the repro in a script to make it easier to run it. To reproduce the bug: $ java -Dderby.database.sqlAuthorization=true org.apache.derby.tools.ij repro.sql . . . ij(C2)> set connection c1; ij(C1)> revoke update on t1 from user2; 0 rows inserted/updated/deleted WARNING 01501: The view V1 has been dropped. ij(C1)> set connection c2; ij(C2)> select * from v1; ERROR 42X05: Table/View 'V1' does not exist. > When a privilege is revoked at table level, Derby should only drop objects > that require that particular privilege and not all the objects that require > some form of privilege on that table. > > > Key: DERBY-1782 > URL: https://issues.apache.org/jira/browse/DERBY-1782 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6 >Reporter: Mamta A. Satoor > Attachments: repro.sql > > > Views/triggers/constraints can depend on different privileges at table level. > As per SQL specification, if the required privilege is revoked, the dependent > objects(Views, triggers and constraints) should get dropped automatically. > Derby 10.2 supports this partially. In Derby 10.2, when any granted privilege > is revoked at a table level, all the objects(views, triggers and constraints) > that require any kind of privilege on that table get dropped. > eg > user1 > create table t1 > grant select, update on t1 to user2 > user2 > create view v1 as select * from user1.t1 -- this view requires SELECT > privilege on user1.t1 and doesn't rely on UPDATE privilege on user1.t1 > user1 > revoke update on t1 from user2 -- in Derby 10.2, this ends up dropping the > view user2.v1 even though it does not rely on that particular privilege on > user1.t1 > Similar behavior exists for column level privileges. When a privilege is > revoked at column level, we should only drop objects that require that > privilege on that particular column list. In Derby 10.2, we end up dropping > all the objects that rely on that privilege type even though they do not > require the particular columns on which privilege is getting revoked. > eg > user1 > create table t1(c11 int, c12 int, c13 int) > grant select(c11,c12) on t1 to user2 > user2 > create view v1 as select c11 from user1.t1 > -- the view above requires SELECT privilege on column c11 in user1.t1 and > doesn't rely on SELECT privilege on column c12 in user1.t1 > user1 > revoke select(c12) on t1 from user2 > -- in Derby 10.2, the above revoke ends up dropping the view user2.v1 even > though it does not rely on SELECT privilege on column c12 in user1.t1 > Both of these behavior manifest from how the permission related system tables > are designed and how Derby keeps the permission dependency information for > the objects. Some solutions for this problem are discussed in DERBY-1539. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1782) When a privilege is revoked at table level, Derby should only drop objects that require that particular privilege and not all the objects that require some form of privile
[ https://issues.apache.org/jira/browse/DERBY-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1782: -- Issue & fix info: [Repro attached] Bug behavior facts: [Deviation from standard] Triaged for 10.5.2. > When a privilege is revoked at table level, Derby should only drop objects > that require that particular privilege and not all the objects that require > some form of privilege on that table. > > > Key: DERBY-1782 > URL: https://issues.apache.org/jira/browse/DERBY-1782 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6 >Reporter: Mamta A. Satoor > > Views/triggers/constraints can depend on different privileges at table level. > As per SQL specification, if the required privilege is revoked, the dependent > objects(Views, triggers and constraints) should get dropped automatically. > Derby 10.2 supports this partially. In Derby 10.2, when any granted privilege > is revoked at a table level, all the objects(views, triggers and constraints) > that require any kind of privilege on that table get dropped. > eg > user1 > create table t1 > grant select, update on t1 to user2 > user2 > create view v1 as select * from user1.t1 -- this view requires SELECT > privilege on user1.t1 and doesn't rely on UPDATE privilege on user1.t1 > user1 > revoke update on t1 from user2 -- in Derby 10.2, this ends up dropping the > view user2.v1 even though it does not rely on that particular privilege on > user1.t1 > Similar behavior exists for column level privileges. When a privilege is > revoked at column level, we should only drop objects that require that > privilege on that particular column list. In Derby 10.2, we end up dropping > all the objects that rely on that privilege type even though they do not > require the particular columns on which privilege is getting revoked. > eg > user1 > create table t1(c11 int, c12 int, c13 int) > grant select(c11,c12) on t1 to user2 > user2 > create view v1 as select c11 from user1.t1 > -- the view above requires SELECT privilege on column c11 in user1.t1 and > doesn't rely on SELECT privilege on column c12 in user1.t1 > user1 > revoke select(c12) on t1 from user2 > -- in Derby 10.2, the above revoke ends up dropping the view user2.v1 even > though it does not rely on SELECT privilege on column c12 in user1.t1 > Both of these behavior manifest from how the permission related system tables > are designed and how Derby keeps the permission dependency information for > the objects. Some solutions for this problem are discussed in DERBY-1539. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1799) SUR: current row not locked when renavigating to it, in queries with indexes
[ https://issues.apache.org/jira/browse/DERBY-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1799: -- Issue & fix info: [Repro attached] Urgency: Normal Triaged for 10.5.2. > SUR: current row not locked when renavigating to it, in queries with indexes > > > Key: DERBY-1799 > URL: https://issues.apache.org/jira/browse/DERBY-1799 > Project: Derby > Issue Type: Bug > Components: SQL, Store >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4 >Reporter: Andreas Korneliussen > Attachments: derby-1799.diff, derby-1799.stat > > > This problem is detected in transactions with isolation level > read-committed/read-uncommitted. > We have a table (T) which has a primary key (a), and a query which does > "select A from T" (an indexed select) > If the result set is scrollable updatable, we expect the current row to be > locked with an update lock. This does not seem to happen when repositioning > to a row which has been already been fetched previously. > The result is that either the wrong row is locked, or if the result set has > been on after last position, no row is locked. > Output from ij: > ij> get scroll insensitive cursor c1 as 'select a from t for update'; > ij> next c1; > A > --- > 1 > ij> select * from SYSCS_DIAG.LOCK_TABLE; > XID|TYPE |MODE|TABLENAME > > |LOCKNAME|STATE|TABLETYPE|LOCK&|INDEXNAME > > > --- > 243|ROW |U |T > > |(1,7) |GRANT|T|1|NULL > > > 243|ROW |S |T > > |(1,1) |GRANT|T|1|SQL060901103455010 > > > 243|TABLE|IX |T > > |Tablelock |GRANT|T|4|NULL > > > 3 rows selected > ij> after last c1; > No current row > ij> previous c1; > A > --- > 3 > ij> select * from SYSCS_DIAG.LOCK_TABLE; > XID|TYPE |MODE|TABLENAME > > |LOCKNAME|STATE|TABLETYPE|LOCK&|INDEXNAME > > > --- > 243|TABLE|IX |T > > |Tablelock |GRANT|T|4|NULL > > > 1 row selected > The last select shows that no row is locked at this point, however we expect > one row to be locked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1831) After a database shutdown, Network Server should invalidate all active connections and an appropriate error message should be thrown at the client while using those connec
[ https://issues.apache.org/jira/browse/DERBY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-1831: -- Issue & fix info: [High Value Fix, Repro attached] (was: [High Value Fix]) Urgency: Normal Bug behavior facts: [Embedded/Client difference] Triaged for 10.5.2. > After a database shutdown, Network Server should invalidate all active > connections and an appropriate error message should be thrown at the client > while using those connections later. > --- > > Key: DERBY-1831 > URL: https://issues.apache.org/jira/browse/DERBY-1831 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1 > Environment: Any >Reporter: Rajesh Kartha > > Any connections currently open during the shutdown should be invalidated. > This would indicate the correct info - that there are no open connections > during the 'show connections' command and the subsequent 'set connection' and > sql should fail with appropriate errors. It works as expected in embedded > mode, but it is more important to behave accordingly in the case of Network > Server where multiple users are connected, rather than throw an obscure error > of "ERROR 58009: A network protocol error was encountered and the connection > . implementation-specific condition for which there was no > architected message " > ij version 10.2 > ij> connect 'jdbc:derby://localhost:1527/testdb;create=true' as connA; > ij> drop table t; > 0 rows inserted/updated/deleted > ij> create table t (id int); > 0 rows inserted/updated/deleted > ij> insert into t values (1); > 1 row inserted/updated/deleted > ij> insert into t values (2); > 1 row inserted/updated/deleted > ij> select * from t; > ID > --- > 1 > 2 > 2 rows selected > -- > --Connection A is still open > -- > ij> connect 'jdbc:derby://localhost:1527/testdb' as connB; > ij(CONNB)> insert into t values (3); > 1 row inserted/updated/deleted > ij(CONNB)> select * from t; > ID > --- > 1 > 2 > 3 > 3 rows selected > -- > -- Should error out saying there are open connections to the database > -- > ij(CONNB)> connect 'jdbc:derby://localhost:1527/testdb;shutdown=true'; > ERROR 08006: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08006, SQLERRMC: > Database 'testdb' shutdown. > ij(CONNB)> disconnect; > -- > --Connection A is still open > -- > ij> show connections; > CONNA - jdbc:derby://localhost:1527/testdb;create=true > No current connection > -- > --Set connection to connection A > -- > ij> set connection connA; > -- > --Try a sql > -- > ij> select * from t; > ERROR 58009: A network protocol error was encountered and the connection has > been terminated: the requested command encountered an unarchitected and > implementation-specific condition for which there was no architected message > ij> > In embedded the ''shutdown=true' closes all active connections to the > database. > ij(CONNB)> connect 'jdbc:derby:testdb;shutdown=true'; > ERROR 08006: Database 'testdb' shutdown. > ij(CONNB)> disconnect; > -- > -- Shows no current connections after a shutdown > -- > ij> show connections; > No current connection > ij> set connection connA; > IJ ERROR: No connection exists with the name CONNA > ij> select * from t; > IJ ERROR: Unable to establish connection > ij> > Furthermore a related issue DERBY-1737 - need to check for existing > connections before shutdown is marked as an improvement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3669) ClientXADataSource fetched from JNDI not identical as originally bound; some properties have String "null" instead of null
[
https://issues.apache.org/jira/browse/DERBY-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen resolved DERBY-3669.
---
Resolution: Fixed
Fix Version/s: 10.6.0.0
Issue & fix info: (was: [Patch Available])
Committed revision 792434.
> ClientXADataSource fetched from JNDI not identical as originally bound; some
> properties have String "null" instead of null
> --
>
> Key: DERBY-3669
> URL: https://issues.apache.org/jira/browse/DERBY-3669
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.6.0.0
>Reporter: Myrna van Lunteren
>Assignee: Knut Anders Hatlen
>Priority: Minor
> Fix For: 10.6.0.0
>
> Attachments: d3669-1a.diff
>
>
> Running the test XAJNDITest (from old xaJNDI.java) with network server fails
> because the XADataSource as bound to JNDI, and then fetch from JNDI are not
> identical.
> This is what the test does to get the XADataSource & to bind & get it from
> JNDI:
>
> ...
> XADataSource xads = J2EEDataSource.getXADataSource();
> String dbName =
> TestConfiguration.getCurrent().getDefaultDatabaseName();
> JDBCDataSource.setBeanProperty(xads, "databaseName", dbName);
> JDBCDataSource.setBeanProperty(xads, "createDatabase", "create");
> JDBCDataSource.setBeanProperty(xads, "description", "XA
> DataSource");
> Hashtable env = new Hashtable();
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> // using a system property - these will have to be passed in
> somehow.
> env.put(Context.PROVIDER_URL, "ldap://"; + ldapServer + ":" +
> ldapPort);
> env.put(Context.SECURITY_AUTHENTICATION, "simple");
> ic.rebind("cn=compareDS, o=" + dnString, xads);
> javax.sql.XADataSource ads =
> (javax.sql.XADataSource)ic.lookup("cn=compareDS, o=" +
> dnString);
> ...
> ---
> Further checking showed that the fetched datasource has a String with value
> "null" rather than a null value for the following properties:
> dataSourceName, connectionAttributes, traceDirectory, traceFile.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-4053) suites.All hang with message java.net.BindException: Address already in use: NET_Bind in derby.log
[ https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen reassigned DERBY-4053: - Assignee: (was: Knut Anders Hatlen) Oops. Just noticed that Kathey had sent a mail to derby-dev asking Mamta to fix this. Unassigning so that I don't block the issue. > suites.All hang with message java.net.BindException: Address already in use: > NET_Bind in derby.log > --- > > Key: DERBY-4053 > URL: https://issues.apache.org/jira/browse/DERBY-4053 > Project: Derby > Issue Type: Bug > Components: Network Server, Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden > Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log, > javacore-20090420-1735.txt, javacore.20090211.123031.4000.0001.txt, > suites.All.out > > > Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang > in the test run. The last test to run successfully was > xtestNestedSavepoints, but I am not sure exactly what test caused the hang. > I took a thread dump which I will attach, which showed network server up and > running but no ClientThread and a ping attempt blocked. > This hang is very similar to the hang that was seen after the fix attempts > for DERBY-1465 but that change was backed out so it is not related to that > change. It could be that the change for DERBY-1465 just made this highly > intermittent problem more likely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
