[jira] Closed: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable
[ https://issues.apache.org/jira/browse/DERBY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa closed DERBY-2592. I have verified that the change to the JavaDoc looks as intended. Thanks for the patch and for committing it, Jazarine and Kristian. > Wrong description of IndexName field in public JavaDoc for LockTable > > > Key: DERBY-2592 > URL: https://issues.apache.org/jira/browse/DERBY-2592 > Project: Derby > Issue Type: Bug > Components: Javadoc >Affects Versions: 10.3.1.4 >Reporter: Olav Sandstaa >Assignee: Jazarine Jamal >Priority: Trivial > Fix For: 10.4.0.0 > > Attachments: DERBY-2592.diff, DERBY-2592_v2.diff > > > The public JavaDoc for LockTable says the following in the description of the > INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE: >INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the > index, this can only happen if this is not a user transaction. > I think the last part is wrong. Normal user transactions might also have a > value in the INDEXNAME. For example, here is part of the lock table for three > user transactions: > XID |TYPE |MODE|TABLENAME |LOCKNAME |STATE|TABLETYPE|INDEXNAME > - > 186 |ROW |X |T2|(1,9) |GRANT|T|NULL > 184 |ROW |S |T2|(1,9) |WAIT |T|NULL > 188 |ROW |X |T1|(1,11)|GRANT|T|NULL > 186 |ROW |S |T1|(1,11)|WAIT |T|NULL > 186 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 188 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 184 |ROW |X |T1|(1,7) |GRANT|T|NULL > 188 |ROW |S |T1|(1,7) |WAIT |T|NULL > Two of the lock entries have an index. I expect this to be the Scan lock that > have been set during traversal of the B-tree. > Proposed fix: remove the last part of the sentence. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3149) Add ant targets for building and running the package private tests against the classes directories
[ https://issues.apache.org/jira/browse/DERBY-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543890 ] Olav Sandstaa commented on DERBY-3149: -- One question about the ant junit-pptesting target: why do we have to include junit.jar explicitly in the CLASSPATH in order for this target to find junit.jar while the ant pptesting target is able to locate the junit.jar in the tools/java directory? Couldn't also the junit-pptesting target use the tools/java/junit.jar file? > Add ant targets for building and running the package private tests against > the classes directories > -- > > Key: DERBY-3149 > URL: https://issues.apache.org/jira/browse/DERBY-3149 > Project: Derby > Issue Type: Sub-task > Components: Build tools, Test >Affects Versions: 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Minor > Fix For: 10.4.0.0 > > Attachments: derby-3149-1a.diff, derby-3149-1a.stat, > derby-3149-1b.diff, derby-3149-2a-conditional_compilation_fix.diff, > derby-3149-2b-conditional_compilation_fix.diff > > > Create ant targets in build.xml to compile and run the package private tests. > The first step will be to run the tests against the classes directories. > Implementing a solution that runs against jars is not technically difficult, > it just brings a host of decisions to be taken... Maybe even more important, > does running against the jars add any value? > The compile will be included in the 'all' target to test the implementation. > Feel free to post your concerns if you think building the package private > tests should be a manual action only. > The tests will also be run as part of junit-all / junitreport. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3149) Add ant targets for building and running the package private tests against the classes directories
[ https://issues.apache.org/jira/browse/DERBY-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543860 ] Olav Sandstaa commented on DERBY-3149: -- I have tested the two new ant targets and they worked fine for me. The only suggestion I have is that it could be a good idea to update the following wiki pages with information about the new ant targets and the new test suite: http://wiki.apache.org/db-derby/DerbyTopLevelJunitTests http://wiki.apache.org/db-derby/DerbyJUnitTesting > Add ant targets for building and running the package private tests against > the classes directories > -- > > Key: DERBY-3149 > URL: https://issues.apache.org/jira/browse/DERBY-3149 > Project: Derby > Issue Type: Sub-task > Components: Build tools, Test >Affects Versions: 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Minor > Fix For: 10.4.0.0 > > Attachments: derby-3149-1a.diff, derby-3149-1a.stat, > derby-3149-1b.diff, derby-3149-2a-conditional_compilation_fix.diff, > derby-3149-2b-conditional_compilation_fix.diff > > > Create ant targets in build.xml to compile and run the package private tests. > The first step will be to run the tests against the classes directories. > Implementing a solution that runs against jars is not technically difficult, > it just brings a host of decisions to be taken... Maybe even more important, > does running against the jars add any value? > The compile will be included in the 'all' target to test the implementation. > Feel free to post your concerns if you think building the package private > tests should be a manual action only. > The tests will also be run as part of junit-all / junitreport. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504155 ] Olav Sandstaa commented on DERBY-2020: -- Thanks a lot for writing the release note, Myrna. I think the release note look very good and I have only some minor comments: 1. If the VM supports "rws" it also supports "rwd" mode. So there are no reverting back from "rwd" to "rws". The only case where Derby revert back from using "rwd" is due to a JVM bug, and then Derby will revert back to use "rw" mode (since the bug is also present when running with "rws"). I propose to change the last sentence in "Rationale for Change" from: "Because not all JVMs support this mechanism, Derby will check if it can use this mechanism and if not, it will revert back to using the "rws" and print an appropriate message indicating same in derby.log" to "Some JVMs have a bug in the support for "rws" and "rwd" mode. Derby will check for this bug, and if it is detected, Derby will revert back to using "rw" mode and print an appropriate message indicating this in derby.log". 2. For the same reason I propose that the second sentence in the "Application Changes required" is changed from: "If not, a message will be printed to derby.log:" to "If Derby detects that your JVM has a bug in the support for "rwd", a message will be printed to derby.log" (as it is written now it seems like this sentence would be written to derby.log every time Derby does not use "rwd" mode. This is no correct. For JVMs older than 1.4.2 "rwd" is not supported, but Derby will not write anything about this to the derby.log) 3. There is a "the the" typo in the second last sentence in the "Rationale for Change" section. Let me know if you want me to upload a new version of the release note or if you incorporate this. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa >Assignee: Olav Sandstaa > Fix For: 10.3.0.0 > > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, > jvmsyncbug_v3.stat, no-disk-cache.png, releaseNote.html, rwd.diff, rwd.stat, > rwd_pre.diff, rwd_pre.stat, rwd_v2.diff > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2657) Performance regression after check-in of svn 531971
[ https://issues.apache.org/jira/browse/DERBY-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2657: - Attachment: TestClient2.java Test client that can be used to show that there has been a performance regression. This test is based on a slightly modified version of the test client found in DERBY-1961. The main change is to add a secondary index to it that is used for the queries. To run this client do: 1. Create and initialize database: java TestClient2 -a initdb -u "jdbc:derby:/tmp/tulldb;create=true" 2. Run test (which does SELECT * FROM ... WHERE SEC_ID= X) with two client threads: java TestClient2 -a select -r 60 -c 2 -u "jdbc:derby:/tmp/tulldb" > Performance regression after check-in of svn 531971 > --- > > Key: DERBY-2657 > URL: https://issues.apache.org/jira/browse/DERBY-2657 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.0.0 > Environment: Solaris/Linux, Sun JDK 5 & 6, IBM 1.5 >Reporter: Olav Sandstaa > Attachments: TestClient2.java > > > After check-in of svn 531971 on DERBY-2537 it seems like there for > some loads are a performance regression of about 10-15 percent. > For more info about this issue see the following mail thread: > http://www.nabble.com/Performance-regression-after-check-in-on-DERBY-2537-(SVN-531971)-t3651494.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2657) Performance regression after check-in of svn 531971
Performance regression after check-in of svn 531971 --- Key: DERBY-2657 URL: https://issues.apache.org/jira/browse/DERBY-2657 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.0.0 Environment: Solaris/Linux, Sun JDK 5 & 6, IBM 1.5 Reporter: Olav Sandstaa After check-in of svn 531971 on DERBY-2537 it seems like there for some loads are a performance regression of about 10-15 percent. For more info about this issue see the following mail thread: http://www.nabble.com/Performance-regression-after-check-in-on-DERBY-2537-(SVN-531971)-t3651494.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494100 ] Olav Sandstaa commented on DERBY-2020: -- Thanks for committing the patch, Kristian. With regards to Craigs concern about introducing a problem on Mac OS X, the answer is that I am not aware of anyone who have tested the patch on OS X. But I tried to take precausion for this problem by first submitting a patch that should hopefully be able to detect this problem on buggy JVMs on OS X and FreeBSD and do a workaround by using "rw" instead of "rwd". But since I did not have access to any of these OSs I was not able to test it. Knut Anders tested the workaround for this bug on FreeBSD, but I have not heard anybody having the itch to test it on OS X yet. It would be great if anybody did - and if the JVM bug is detected on OS X you should see a statement about this in the derby.log. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Fix For: 10.3.0.0 > > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, > jvmsyncbug_v3.stat, no-disk-cache.png, rwd.diff, rwd.stat, rwd_pre.diff, > rwd_pre.stat, rwd_v2.diff > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2020: - Derby Info: [Patch Available] > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, > jvmsyncbug_v3.stat, no-disk-cache.png, rwd.diff, rwd.stat, rwd_pre.diff, > rwd_pre.stat, rwd_v2.diff > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2020: - Attachment: rwd_v2.diff The only change in this patch (rwd_v2.diff) is to do the actual change of mode for opening log files from "rws" to "rwd" and some corresponding changes in comments. I have run derbyall and the JUnit suite with any errors. The patch is ready for review and commit. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, > jvmsyncbug_v3.stat, no-disk-cache.png, rwd.diff, rwd.stat, rwd_pre.diff, > rwd_pre.stat, rwd_v2.diff > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable
Wrong description of IndexName field in public JavaDoc for LockTable Key: DERBY-2592 URL: https://issues.apache.org/jira/browse/DERBY-2592 Project: Derby Issue Type: Bug Components: Javadoc Affects Versions: 10.3.0.0 Reporter: Olav Sandstaa Priority: Trivial The public JavaDoc for LockTable says the following in the description of the INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE: INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the index, this can only happen if this is not a user transaction. I think the last part is wrong. Normal user transactions might also have a value in the INDEXNAME. For example, here is part of the lock table for three user transactions: XID |TYPE |MODE|TABLENAME |LOCKNAME |STATE|TABLETYPE|INDEXNAME - 186 |ROW |X |T2|(1,9) |GRANT|T|NULL 184 |ROW |S |T2|(1,9) |WAIT |T|NULL 188 |ROW |X |T1|(1,11)|GRANT|T|NULL 186 |ROW |S |T1|(1,11)|WAIT |T|NULL 186 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 188 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 184 |ROW |X |T1|(1,7) |GRANT|T|NULL 188 |ROW |S |T1|(1,7) |WAIT |T|NULL Two of the lock entries have an index. I expect this to be the Scan lock that have been set during traversal of the B-tree. Proposed fix: remove the last part of the sentence. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2020: - Derby Info: [Patch Available] > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, > jvmsyncbug_v3.stat, no-disk-cache.png, rwd.diff, rwd.stat, rwd_pre.diff, > rwd_pre.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2020: - Attachment: rwd_pre.stat rwd_pre.diff This patch (rwd_pre.diff) contains changes in comments and a method name that could be committed independently and in advance of the actual change of file mode for log files. The main changes are: 1. Rename the method called supportsRws() to supportWriteSync() in WritableStorageFactory and all of its implementation. 2. Fixed code comments referring to "rws" to also include "rwd" so that the comments also will be valid if rwd is used. The patch does not include any functional changes. The purpose of submitting this separately is to keep the size of the actual patch that changes the file mode small. Derbyall and the Junit suite have been run with zero failures. The patch is ready for review and commit. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, > jvmsyncbug_v3.stat, no-disk-cache.png, rwd.diff, rwd.stat, rwd_pre.diff, > rwd_pre.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490368 ] Olav Sandstaa commented on DERBY-2020: -- Knut Anders, thanks for committing the patch and particularly for running a test on a buggy JVM to verify that the the buq was detected and that the workaround was triggered. I will submit a new patch shortly which do the changing of mode for opening of log files. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, > jvmsyncbug_v3.stat, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2020: - Attachment: jvmsyncbug_v3.stat jvmsyncbug_v3.diff This patch includes changes based on comments from Suresh. The check for the JVM bug is now done in openLogFileInWriteMode. The test will be done on the log file that is going to be used. The check does first open the file in "rw" mode to ensure that the file exists and then re-opens it in "rws" mode. If a FileNotFoundExceptions is thrown, Derby will switch from using "write sync" mode to doing explicite syncing. The test is only done once when the first log file is opened in rws mode. This patch does no change to the rws mode used by the log file writing. I have run derbyall and the JUnit suite with no errors on Solaris 10. The patch is ready for review and commit. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, > jvmsyncbug_v3.stat, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489241 ] Olav Sandstaa commented on DERBY-2020: -- Thanks for comments, Suresh. 1) The reason for creating a new file "rwstest.tmp" was due to I wanted to be able to have this check done early and in a single place during the boot of the log system. At the place I decided to add the test the boot code does not know the name of the first log file and a log file does not even have to exist at that time. I did not want to have to scan the log directory to be able to find an existing log file that could be used for testing. 2) I think your comment about read only databases are very valid. By reading the code it seems like my new code could end up throwing exceptions that would not be handled properly and lead to failed start-ups for read-only databases. I will address both of these issues by moving the testing for this JVM bug into the method LogToFile.openLogFileInWriteMode(). At this point Derby both know the name of the log file to be opened first and this code will not be called for the readonly db cases. The only "drawback" by having this code in this method is that there will be need for some extra logic to ensure that this check is only run once. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2020: - Attachment: jvmsyncbug_v2.stat jvmsyncbug_v2.diff Updated patch for how to detect "JVM bug for rws/rwd mode" (see DERBY-1) based on the second comment from Knut Anders. The only change to in this version of the patch is that it now only catches the FileNotFoundException instead of catching all IOExpections. I have run derbyall and the JUnit suite without any errors with JDK5 on Solaris 10. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483962 ] Olav Sandstaa commented on DERBY-2020: -- Hi Knut Anders, Thanks for the review comments - and thanks for changing your mind about your first comment - given that I do not have any way to verify this I would happily have made any changes you suggested :-) I agree with your second comment and will post an updated patch. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2020: - Attachment: jvmsyncbug.stat jvmsyncbug.diff This patch (jvmsyncbug.diff) is a proposal for how we can handle the JVM bug that have been reported for some JVMs on Mac OS and FreeBSD. The main change is to handle this bug as part of the "error handling" after failing to open a log file in "rws" mode to explicitely checking if this error is present. The purpose of this change is to be able to handle problems when the log file is opened in "rws" and "rwd" mode (the current code in Derby only handles failures for the "rws" mode). The patch do the following during booting of Derby's logging module to detect if the JVM bug is present 1. Creates a file in the log directory using "rw" mode - this should succeed on all JVMs 2. Re-opens the same file using "rws" mode. If this operation failes, the JVM bug is present. An error message is written to the derby log file (not THE LOG but derby.log). If the JVM bug is present, Derby changes from using synchronized writes for the log to use normal writes followed by an explicite sync. The patch also removes the current code for handling this problem. The patch does NOT include the proposed change from using "rws" to "rwd" mode. I do not have strong opinions about whether Derby should handle this JVM bug or not. I have run derbyall and the JUnit test suite on JDK 5 on Solaris 10. I have not run it with any of the JVMs with the reported JVM bug (I do no longer have a FreeBSD machine - and I have never had a Mac). Feel free to review and commit the patch if you think this is a good thing to have in Derby. If you think this code for handling a JVM specific error should not be in the code please say so. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, > no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482754 ] Olav Sandstaa commented on DERBY-2020: -- Suresh and Mike, Thanks for the comments. I agree that Derby should not have to do extra work to handle something that is a JVM bug. Still, since there already is code to handle this situation I think it is worth to maintain this functionality given that it does not affect the normal operation of Derby. And I think Derby running with "rwd" mode for these bug vms that do not sync is much more likely to result in a non-recoverable database when running on a disk that has the write cache enabled. With the write cache enabled on the disk, the data will in most situations be written to disk even when there is a system crash or power failure (but with no guarantee). With the data only being written to the file system cache and no syncing to disk there is a much longer time period where you do not have the log synced to disk. I will make a proposal for a fix for how to handle this JVM bug based on opening a file on the log device (I agree with Suresh that using the tmp device is not a good idea). To answer Suresh's second question. Yes, after crash that occurs while updating a file in "rwd" mode everything that is related to the content of the file and being able to read the file must be updated on disk. This should include the length of the file. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480411 ] Olav Sandstaa commented on DERBY-2020: -- Thanks for the comments, Knut Anders. I will go through the comments and update the references to "rws". As for a solution to the JVM bug in some VMs on MAC, I was not aware about the difference in how this bug(s) manifested itself when opening in rws and rwd mode. I have read to comments in the workaround and in DERBY-1. If I understand it correctly we need at least open a file once in rws mode in order to decide if we have this bug. Right now this is done the first time LogToFile.openLogFileInWriteMode() is called. I want to change this to always use rwd instead of rws, but this will not detect this problem. Some possible solutions could be: 1. The first time LogToFile.openLogFileInWriteMode() is called, try to open the file in rws mode to see if we get the exception. If no exception is thrown, re-open the file in rwd mode. If an exception is thrown revert to use rw mode. 2. Move this check to DirStorageFactory4.supportsRws(). Today, this function will return true for all JVMs 1.4.2 or newer. I think it might be more logical to have a check in this method to determine if there are any issues that should prevent us from using rws or rwd. For instance, the first time this method was called we could: 1. Create a file in Derby's tmp directory using "rw" mode. 2. Close it. 3. Reopen the file in rws mode. 4. If an exception is thrown, then make the method return false (ie. this JVM does not support rws/rwd). I think alternative 2 is a cleaner approach. Since I do not have a machine running Mac OS I will have no way to actually test that this works. I will make a patch for it hoping that someone will test it out. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480050 ] Olav Sandstaa commented on DERBY-2020: -- I have discussed this change with someone working on this part of Java within Sun. The feedback I have received is that the following text in the JavaDoc for the RandomAccessFile constructor (see http://java.sun.com/j2se/1.4.2/docs/api/java/io/RandomAccessFile.html): "If the file resides on a local storage device then when an invocation of a method of this class returns it is guaranteed that all changes made to the file by that invocation will have been written to that device. This is useful for ensuring that critical information is not lost in the event of a system crash. If the file does not reside on a local device then no such guarantee is made." applies to both "rws" and "rwd" mode (as the text says). So with regards to the content of the file and the possibility to read the data from the file after a system crash, these two options should have identical behavior and give identical guarantees. The only optimizations that "rwd" is allowed to do is to not update meta-data that are not critical for reading the file data. If data that has been appended to a file is lost in a crash, the "critical information is not lost" requirement is broken, and the implementation is non-conforming to the spec. This change gives a large performance benefit on some operating systems. As far as I can see, this should be a safe change to Derby and I propose this patch being reviewed and committed. I have run derbyall and the JUnit test suite, and as expected I did not see any problems. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2020: - Derby Info: [Patch Available] > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa reassigned DERBY-2020: Assignee: Olav Sandstaa > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: https://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2029) Query timeout does not take effect if server machine crashes
[ https://issues.apache.org/jira/browse/DERBY-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478390 ] Olav Sandstaa commented on DERBY-2029: -- I have not tried to test with the other failures you mention, but I would expect this to be: unplugging the network cable on the client machine: depending on which OS you run, the timeout would work unplugging the network cable on the server machine: the timeout would not work and Derby would hang "forever" killing the derby server: the timeout would work If the timout works or not in these cases depends on whether the TCP-layer is able to detect that the server is no longer available. If "crashing" the server or unplugging the net on the server, the TCP layer on the client will not be informed about this for a rather long time period. > Query timeout does not take effect if server machine crashes > > > Key: DERBY-2029 > URL: https://issues.apache.org/jira/browse/DERBY-2029 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.2.2.0, 10.3.0.0 > Environment: Solaris 10, JDK 1.5 >Reporter: Olav Sandstaa >Priority: Minor > Attachments: QueryTimeout.java > > > An application using the client driver will hang "infinite" if the > server machine running the Derby server crashes during execution of a > query even if it has specified a query timeout using > Statement.setQueryTimeout(). > This problem can be reproduced (at least on Solaris 10) by: > 1. starting a Derby server on one machine and a Derby client on the second > machine. > 2. In a Java program, create a connection and a statement and set the > query timeout for the statement to a few seconds by: > Statement.setQueryTimeout(10) > 3. Execute a query that take some time (more than 10 seconds). > 4. During execute of the query, take the power on the machine running > the Derby server. > 5. Your program will hang "infinite". > I will post a short repro program that can be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2328) Reduce monitor contention in SinglePool
[ https://issues.apache.org/jira/browse/DERBY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476570 ] Olav Sandstaa commented on DERBY-2328: -- Adding comments sent earlier today to derby-dev when JIRA was unavailable: = I have downloaded and reviewed the patch. I like the introduction of the CompatibilitySpace interface and having to explicitly to create compatibility spaces. It mades the code more readable. Also removing the hash table from SinglePool is good both for simplifying the code, readability and performance (CPU and monitor contention). The patch looks very good. I have only some very minor nits: * java/engine/org/apache/derby/impl/services/locks/LockSpace.java: -since you have changed the signature of the LockSpace constructor you should consider adding JavaDoc describing the new parameter (Object owner). -it might also be an idea to explain the "owner" concept in the JavaDoc for the class since this is a new concept you are introducing? (and if you change the JavaDoc for the class, you can probably also change the sentence refeering the "a hashtable keyed by..." to a "hash map keyed by") I have run the derbyall and Junit test suites with the patch. Only the two tests that currently fail in the thinderbox test failed. +1 to commit this patch. Thanks for the work on this, Knut Anders! Regards, Olav > Reduce monitor contention in SinglePool > --- > > Key: DERBY-2328 > URL: https://issues.apache.org/jira/browse/DERBY-2328 > Project: Derby > Issue Type: Sub-task > Components: Performance, Services >Affects Versions: 10.3.0.0 >Reporter: Knut Anders Hatlen > Assigned To: Knut Anders Hatlen >Priority: Minor > Attachments: derby-2328.diff, derby-2328.stat, unused.diff > > > When multiple threads enter the lock manager, there might be contention on > SinglePool's monitor. The contention should be reduced in order to improve > scalability. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2276) ApacheCon 2006 presentations
[ https://issues.apache.org/jira/browse/DERBY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olav Sandstaa updated DERBY-2276: - Attachment: DerbyPerfDurability.pdf Attaching my presentation on Configuring Derby for Performance and Durability, given at ApacheCon 2006 US in Austin. Jean, thanks for making these presentations available on the Derby web site. > ApacheCon 2006 presentations > > > Key: DERBY-2276 > URL: https://issues.apache.org/jira/browse/DERBY-2276 > Project: Derby > Issue Type: Task > Components: Web Site >Reporter: Rick Hillegas > Attachments: DerbyPerfDurability.pdf, JavaInTheDatabase.pdf > > > This is a place to attach our presentations for ApacheCon 2006. Thanks to > Jean for volunteering to wire these into the web site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2254) Assert during log file switch: log file position exceeded max log file size
[ https://issues.apache.org/jira/browse/DERBY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466490 ] Olav Sandstaa commented on DERBY-2254: -- Just for the record: I tried to restart the database to see if it was able to recover. Not surpricingly, after about three hours into the recovery, it was aborted with the same assert and the following call stack: Exception trace: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) at org.apache.derby.impl.store.raw.log.Scan.getNextRecordForward(Scan.java:973) at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:206)at org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1176) at org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:811) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:308) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1994) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:546) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:988) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1994) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:546) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:746) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:182) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1994) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1829) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1695) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1575) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:994) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:542) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1633) at org.apache.derby.impl.jdbc.EmbedConnection.(EmbedConnection.java:223) at org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:73) at org.apache.derby.impl.jdbc.EmbedConnection40.(EmbedConnection40.java:54) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:64) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:210) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:117) at java.sql.DriverManager.getConnection(DriverManager.java:582) at java.sql.DriverManager.getConnection(DriverManager.java:185) at com.sun.derby.perf.clients.tpcb.DBConnection.loadDriver(DBConnection.java:140) at com.sun.derby.perf.clients.tpcb.DBConnection.(DBConnection.java:49) at com.sun.derby.perf.clients.tpcb.TPCBClient.run(TPCBClient.java:132) at com.sun.derby.perf.clients.tpcb.TPCBClient.main(TPCBClient.java:381) > Assert during log file switch: log file position exceeded max log file size > --- > > Key: DERBY-2254 > URL: https://issues.apache.org/jira/browse/DERBY-2254 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.0.0 > Environment: Solaris 10, Java SE 6 build 104 >Reporter: Olav Sandstaa > > When running simple tpc-b like transactions against a embedded Derby based on > a SANE build of trunk the following assertion occurs for the background > thread and all user threads: >org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log > file position exceeded max log file size > This seems to occur during a switch to a new log file. > derby.log contains the following call stack for the background thread: > Exception trace: > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file
[jira] Commented: (DERBY-2254) Assert during log file switch: log file position exceeded max log file size
[ https://issues.apache.org/jira/browse/DERBY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466475 ] Olav Sandstaa commented on DERBY-2254: -- Mike, thank you for commenting on this and for explaining what you think are the issues behind this problem. I agree that the best solution seems be to fix this so that the background thread can do log file switching without waiting for the checkpoing to complete. Some questions somebody maybe know the answer to: -What is the reason for most of the log files having the default size of 1 MB but a few (4) log files grow to 268 kB before switching? -The crash occurs after having produced about 1 GB of log. Is there a hard limit on 1 GB before the checkpoint must be completed? This crash happened during some experimental testing where I want to study data rates to and from the disks during high load. I can do this with a much smaller database buffer so being able to run with a 18 GB database buffer is not an urgent issue for me right now. > Assert during log file switch: log file position exceeded max log file size > --- > > Key: DERBY-2254 > URL: https://issues.apache.org/jira/browse/DERBY-2254 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.0.0 > Environment: Solaris 10, Java SE 6 build 104 >Reporter: Olav Sandstaa > > When running simple tpc-b like transactions against a embedded Derby based on > a SANE build of trunk the following assertion occurs for the background > thread and all user threads: >org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log > file position exceeded max log file size > This seems to occur during a switch to a new log file. > derby.log contains the following call stack for the background thread: > Exception trace: > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file > position exceeded max log file size > at > org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) > at > org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) > at > org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) > at > org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) > at > org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) > at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357) > at > org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439) > at > org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) > at > org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) > at > org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) > at java.lang.Thread.run(Thread.java:619) > 2007-01-17 23:09:48.638 GMT Thread[derby.rawStoreDaemon,5,derby.daemons] > Cleanup action starting > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file > position exceeded max log file size > at > org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) > at > org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) > at > org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) > at > org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) > at > org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) > at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540) > at > org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357) > at > org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439) > at > org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) > at > org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) > at > org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) > at java.lang.Thread.run(Thread.java:619) > Cleanup action completed > For my user threads the call stack is similar: > Database Class Loader started - derby
[jira] Commented: (DERBY-2254) Assert during log file switch: log file position exceeded max log file size
[ https://issues.apache.org/jira/browse/DERBY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465881 ] Olav Sandstaa commented on DERBY-2254: -- The crash happened when running simple transactions (3 updates, 1 insert, 1 select) against a database with 10 GB user data (total data volume 17 GB). Derby was configured with a 18 GB database buffer. The crash occured about 2 hours after re-starting an existing database. The load consisted of 64 clients running transactions back-to-back. Since the database was "just" started most of the transactions had to read data from the disk, thus there were about 60 concurrent read requests for getting data into the database buffer. At the same time the single back-ground thread was having a hard time to keep up writing out dirty data to the disk. At this time there were plenty of free room in the page cache so no data blocks were "evicted" out to disk by the user threads. Since the background thread were not able to flush data pages fast enough it was also unable to reclaim log files. So the amount of log kept growing. One thing I do not understand is that most of the log files have their normal size while some are very close to the max log file size. Here is a list of the files in the log directory after the crash: -rw-r- 1 olav 48 Jan 17 22:09 log.ctrl -rw-r- 1 olav 48 Jan 17 22:09 logmirror.ctrl -rw-r- 1 olav 1060411 Jan 17 22:09 log1181.dat -rw-r- 1 olav 1067038 Jan 17 22:09 log1182.dat -rw-r- 1 olav 1049488 Jan 17 22:09 log1183.dat -rw-r- 1 olav 1050176 Jan 17 22:09 log1184.dat -rw-r- 1 olav 1050758 Jan 17 22:10 log1185.dat -rw-r- 1 olav 1050583 Jan 17 22:10 log1186.dat -rw-r- 1 olav 1050178 Jan 17 22:10 log1187.dat -rw-r- 1 olav 1054465 Jan 17 22:10 log1188.dat -rw-r- 1 olav 1051730 Jan 17 22:11 log1189.dat -rw-r- 1 olav 1052601 Jan 17 22:11 log1190.dat -rw-r- 1 olav 268435436 Jan 17 22:55 log1191.dat -rw-r- 1 olav 1048576 Jan 17 22:55 log1192.dat -rw-r- 1 olav 1048576 Jan 17 22:55 log1193.dat -rw-r- 1 olav 1048576 Jan 17 22:55 log1194.dat -rw-r- 1 olav 1048576 Jan 17 22:55 log1195.dat -rw-r- 1 olav 1048576 Jan 17 22:55 log1196.dat -rw-r- 1 olav 1048576 Jan 17 22:55 log1197.dat -rw-r- 1 olav 268435434 Jan 17 23:23 log1198.dat -rw-r- 1 olav 1048576 Jan 17 23:23 log1199.dat -rw-r- 1 olav 1048576 Jan 17 23:23 log1200.dat -rw-r- 1 olav 1048576 Jan 17 23:23 log1201.dat -rw-r- 1 olav 1048576 Jan 17 23:23 log1202.dat -rw-r- 1 olav 268435429 Jan 17 23:46 log1203.dat -rw-r- 1 olav 1048576 Jan 17 23:46 log1204.dat -rw-r- 1 olav 1048576 Jan 17 23:46 log1205.dat -rw-r- 1 olav 1048576 Jan 17 23:46 log1206.dat -rw-r- 1 olav 1048576 Jan 17 23:46 log1207.dat -rw-r- 1 olav 1048576 Jan 17 23:46 log1208.dat -rw-r- 1 olav 1048576 Jan 17 23:46 log1209.dat -rw-r- 1 olav 1048576 Jan 17 23:46 log1210.dat -rw-r- 1 olav 268435456 Jan 18 00:09 log1211.dat -rw-r- 1 olav0 Jan 18 00:09 log1212.dat In org.apache.derby.impl.store.raw.log.LogCounter the following constant is defined // reserve top 4 bits in log file size for future use public static final long MAX_LOGFILE_SIZE = (long)0x0FFFL; // 268435455 and the assert is defined as: SanityManager.ASSERT(filepos < MAX_LOGFILE_SIZE, "log file position exceeded max log file size"); Comparing the constant MAX_LOGFILE_SIZE (268435455) with the length of the second last file above (268435456) it actually seems like this log file has become a byte too long. > Assert during log file switch: log file position exceeded max log file size > --- > > Key: DERBY-2254 > URL: https://issues.apache.org/jira/browse/DERBY-2254 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.0.0 > Environment: Solaris 10, Java SE 6 build 104 >Reporter: Olav Sandstaa > > When running simple tpc-b like transactions against a embedded Derby based on > a SANE build of trunk the following assertion occurs for the background > thread and all user threads: >org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log > file position exceeded max log file size > This seems to occur during a switch to a new log file. > derby.log contains the following call stack for the background thread: > Exception trace: > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file > position exceeded max log file size > at > org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) > at > org.apache.derby.impl.store.raw.log.LogCounter
[jira] Created: (DERBY-2254) Assert during log file switch: log file position exceeded max log file size
Assert during log file switch: log file position exceeded max log file size --- Key: DERBY-2254 URL: https://issues.apache.org/jira/browse/DERBY-2254 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.0.0 Environment: Solaris 10, Java SE 6 build 104 Reporter: Olav Sandstaa When running simple tpc-b like transactions against a embedded Derby based on a SANE build of trunk the following assertion occurs for the background thread and all user threads: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size This seems to occur during a switch to a new log file. derby.log contains the following call stack for the background thread: Exception trace: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540) at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357) at org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439) at org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416) at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) at org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) at org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) at java.lang.Thread.run(Thread.java:619) 2007-01-17 23:09:48.638 GMT Thread[derby.rawStoreDaemon,5,derby.daemons] Cleanup action starting org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540) at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357) at org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439) at org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416) at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) at org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) at org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) at java.lang.Thread.run(Thread.java:619) Cleanup action completed For my user threads the call stack is similar: Database Class Loader started - derby.database.classpath='' 2007-01-17 23:09:36.401 GMT Thread[Thread-51,5,main] (XID = 12632406), (SESSIONID = 51), (DATABASE = /export/home/tmp/derby-db), (DRDAID = null), Cleanup action starting 2007-01-17 23:09:36.401 GMT Thread[Thread-51,5,main] (XID = 12632406), (SESSIONID = 51), (DATABASE = /export/home/tmp/derby-db), (DRDAID = null), Failed Statement is: UPDATE accounts SET abal = abal + ? WHERE aid = ? AND bid = ? org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) at org.apache.derby.impl.store.raw.data.LoggableActions.doAction(LoggableActions.j
[jira] Created: (DERBY-2184) QuickStart section of java/testing/README.htm should contain Sun JDK6 as supported java version for running tests
QuickStart section of java/testing/README.htm should contain Sun JDK6 as supported java version for running tests - Key: DERBY-2184 URL: http://issues.apache.org/jira/browse/DERBY-2184 Project: Derby Issue Type: Bug Components: Documentation, Test Affects Versions: 10.2.2.0, 10.3.0.0 Reporter: Olav Sandstaa Priority: Trivial The QuickStart section in java/testing/README.htm lists the java versions that are supported for running Derby tests. JDK6 should be added to this list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ http://issues.apache.org/jira/browse/DERBY-2020?page=all ] Olav Sandstaa updated DERBY-2020: - Attachment: rwd.diff rwd.stat This patch changes the sync mode of the log files from "rws" to "rwd". The purpose is to let other people test this change out to see if it has any impact on performance or any issues with regards to recoverability after failure. The patch is NOT intended for inclusion in Derby (yet). > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: http://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png, rwd.diff, rwd.stat > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-2090) Broken link in Reference manual
[ http://issues.apache.org/jira/browse/DERBY-2090?page=all ] Olav Sandstaa closed DERBY-2090. Verified that the new link works in the latest build of the documentation. Thanks for fixing this problem and for committing the patch, Kim and Knut Anders. > Broken link in Reference manual > --- > > Key: DERBY-2090 > URL: http://issues.apache.org/jira/browse/DERBY-2090 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: All >Reporter: Olav Sandstaa > Assigned To: Kim Haase >Priority: Trivial > Fix For: 10.3.0.0, 10.2.1.8 > > Attachments: DERBY-2090.diff, DERBY-2090.zip > > > In the section "javax.sql: JDBC Extensions" in the Reference manual the > following link: > > http://java.sun.com/products/jdbc/jdbc20.stdext.javadoc/javax/sql/package-summary.html > is no longer valid. > It could possibly be replaced with: >http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/package-summary.html > or maybe even better just be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2090) Broken link in Reference manual
[ http://issues.apache.org/jira/browse/DERBY-2090?page=comments#action_12450676 ] Olav Sandstaa commented on DERBY-2090: -- I have looked at the HTML file and the change looks good. I agree that it is better to point to a web page that contains links to documentation for more than one version of Java SE than a page that only has the documentation for one version of Java SE. Thanks for fixing this, Kim. Regarding the sentence referring to "three methods" I have no good answer to what it means or what it refers to. Hopefully someone else know what this is supposed to refer to. > Broken link in Reference manual > --- > > Key: DERBY-2090 > URL: http://issues.apache.org/jira/browse/DERBY-2090 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: All >Reporter: Olav Sandstaa > Assigned To: Kim Haase >Priority: Trivial > Attachments: DERBY-2090.diff, DERBY-2090.zip > > > In the section "javax.sql: JDBC Extensions" in the Reference manual the > following link: > > http://java.sun.com/products/jdbc/jdbc20.stdext.javadoc/javax/sql/package-summary.html > is no longer valid. > It could possibly be replaced with: >http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/package-summary.html > or maybe even better just be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2090) Broken link in Reference manual
Broken link in Reference manual --- Key: DERBY-2090 URL: http://issues.apache.org/jira/browse/DERBY-2090 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.3.0.0 Environment: All Reporter: Olav Sandstaa Priority: Trivial In the section "javax.sql: JDBC Extensions" in the Reference manual the following link: http://java.sun.com/products/jdbc/jdbc20.stdext.javadoc/javax/sql/package-summary.html is no longer valid. It could possibly be replaced with: http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/package-summary.html or maybe even better just be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ http://issues.apache.org/jira/browse/DERBY-2020?page=comments#action_12446971 ] Olav Sandstaa commented on DERBY-2020: -- I agree that it would be good to get a clarification of this into the specification. I will try to discuss this with someone working in Sun's Java team and possibly enter a bug or a request for improvement for this. Still, I think it is good to have some data from different OSes on how this affect the performance in order to decide if this is worth the effort to try to change how the log is written. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: http://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2029) Query timeout does not take effect if server machine crashes
[ http://issues.apache.org/jira/browse/DERBY-2029?page=all ] Olav Sandstaa updated DERBY-2029: - Attachment: QueryTimeout.java This program can be used for reproducing this problem. In addition to this program you need at least two machines and be willing to take the power on one of them. Here is how to reproduce the problem: 1. Start a Derby server on one of the machines 2. Change the jdbc url to your server and port number 3. Start this program on the second machine 4. Within 1 minute after starting the program, take the power on the machine running the Derby server. 5. This program will hang "infinite" long. If you skip step 4 above, the program get a (query) timeout after about 1 minute. > Query timeout does not take effect if server machine crashes > > > Key: DERBY-2029 > URL: http://issues.apache.org/jira/browse/DERBY-2029 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.2.1.8, 10.2.2.0, 10.3.0.0 > Environment: Solaris 10, JDK 1.5 >Reporter: Olav Sandstaa >Priority: Minor > Attachments: QueryTimeout.java > > > An application using the client driver will hang "infinite" if the > server machine running the Derby server crashes during execution of a > query even if it has specified a query timeout using > Statement.setQueryTimeout(). > This problem can be reproduced (at least on Solaris 10) by: > 1. starting a Derby server on one machine and a Derby client on the second > machine. > 2. In a Java program, create a connection and a statement and set the > query timeout for the statement to a few seconds by: > Statement.setQueryTimeout(10) > 3. Execute a query that take some time (more than 10 seconds). > 4. During execute of the query, take the power on the machine running > the Derby server. > 5. Your program will hang "infinite". > I will post a short repro program that can be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2029) Query timeout does not take effect if server machine crashes
Query timeout does not take effect if server machine crashes Key: DERBY-2029 URL: http://issues.apache.org/jira/browse/DERBY-2029 Project: Derby Issue Type: Bug Components: JDBC, Network Client Affects Versions: 10.2.1.8, 10.2.2.0, 10.3.0.0 Environment: Solaris 10, JDK 1.5 Reporter: Olav Sandstaa Priority: Minor An application using the client driver will hang "infinite" if the server machine running the Derby server crashes during execution of a query even if it has specified a query timeout using Statement.setQueryTimeout(). This problem can be reproduced (at least on Solaris 10) by: 1. starting a Derby server on one machine and a Derby client on the second machine. 2. In a Java program, create a connection and a statement and set the query timeout for the statement to a few seconds by: Statement.setQueryTimeout(10) 3. Execute a query that take some time (more than 10 seconds). 4. During execute of the query, take the power on the machine running the Derby server. 5. Your program will hang "infinite". I will post a short repro program that can be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2026) Setting a login timeout in client driver can lead to query timeout
[ http://issues.apache.org/jira/browse/DERBY-2026?page=all ] Olav Sandstaa updated DERBY-2026: - Attachment: LoginTimeout.java This is a repro showing that setting the login timeout to 10 seconds makes the folloiwng query to fail with the exception shown in the JIRA report. To run the repro: 1. start a Derby network server 2. update the jdbcUrl in the java program with the correct server and port number 3. Run the repro program. This program should produce the execption after about 10 seconds. To make the program succeed, remove the call to DriverManager.setLoginTimeout(). Note that the program then might take about 2 to 10 minutes to complete the query. This repro will fail to reproduce the bug if you have a machine that is much faster than than the one I am using or if you are running on an operating system that does not support setting a timeout on blocking socket calls. > Setting a login timeout in client driver can lead to query timeout > -- > > Key: DERBY-2026 > URL: http://issues.apache.org/jira/browse/DERBY-2026 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.3.0.0 > Environment: Client driver on most platforms >Reporter: Olav Sandstaa >Priority: Minor > Attachments: LoginTimeout.java > > > Setting the login timeout by using DriverManager.setLoginTimeout(int > seconds) also affects the amount of time the client driver is waiting > for a query to finish. For instance, setting the login timeout to 10 > seconds will result in any queries taking more than 10 seconds to fail > with the following exception: > Exception thrown: java.sql.SQLException: A communications error has been > detected: Read timed out. > java.sql.SQLException: A communications error has been detected: Read timed > out. > at > org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46) > at > org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345) > at > org.apache.derby.client.am.Statement.executeQuery(Statement.java:414) > at LoginTimeout.main(LoginTimeout.java:53) > Caused by: org.apache.derby.client.am.DisconnectException: A communications > error has been detected: Read timed out. > at > org.apache.derby.client.net.NetAgent.throwCommunicationsFailure(NetAgent.java:408) > at org.apache.derby.client.net.Reply.fill(Reply.java:176) > at > org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java:215) > at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) > at > org.apache.derby.client.net.Reply.startSameIdChainParse(Reply.java:1147) > at > org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(NetStatementReply.java:51) > at > org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(StatementReply.java:40) > at > org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(NetStatement.java:139) > at > org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Statement.java:1341) > at > org.apache.derby.client.am.Statement.flowExecute(Statement.java:1977) > at > org.apache.derby.client.am.Statement.executeQueryX(Statement.java:420) > at > org.apache.derby.client.am.Statement.executeQuery(Statement.java:405) > ... 1 more > Caused by: java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:129) > at org.apache.derby.client.net.Reply.fill(Reply.java:174) > ... 11 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2026) Setting a login timeout in client driver can lead to query timeout
Setting a login timeout in client driver can lead to query timeout -- Key: DERBY-2026 URL: http://issues.apache.org/jira/browse/DERBY-2026 Project: Derby Issue Type: Bug Components: JDBC, Network Client Affects Versions: 10.3.0.0 Environment: Client driver on most platforms Reporter: Olav Sandstaa Priority: Minor Setting the login timeout by using DriverManager.setLoginTimeout(int seconds) also affects the amount of time the client driver is waiting for a query to finish. For instance, setting the login timeout to 10 seconds will result in any queries taking more than 10 seconds to fail with the following exception: Exception thrown: java.sql.SQLException: A communications error has been detected: Read timed out. java.sql.SQLException: A communications error has been detected: Read timed out. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345) at org.apache.derby.client.am.Statement.executeQuery(Statement.java:414) at LoginTimeout.main(LoginTimeout.java:53) Caused by: org.apache.derby.client.am.DisconnectException: A communications error has been detected: Read timed out. at org.apache.derby.client.net.NetAgent.throwCommunicationsFailure(NetAgent.java:408) at org.apache.derby.client.net.Reply.fill(Reply.java:176) at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java:215) at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) at org.apache.derby.client.net.Reply.startSameIdChainParse(Reply.java:1147) at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(NetStatementReply.java:51) at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(StatementReply.java:40) at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(NetStatement.java:139) at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Statement.java:1341) at org.apache.derby.client.am.Statement.flowExecute(Statement.java:1977) at org.apache.derby.client.am.Statement.executeQueryX(Statement.java:420) at org.apache.derby.client.am.Statement.executeQuery(Statement.java:405) ... 1 more Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.apache.derby.client.net.Reply.fill(Reply.java:174) ... 11 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ http://issues.apache.org/jira/browse/DERBY-2020?page=comments#action_12445865 ] Olav Sandstaa commented on DERBY-2020: -- A discussion related to this issue has taken place in the following mail thread: http://www.nabble.com/Options-for-syncing-of-log-to-disk-tf2188615.html > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: http://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ http://issues.apache.org/jira/browse/DERBY-2020?page=all ] Olav Sandstaa updated DERBY-2020: - Attachment: no-disk-cache.png disk-cache.png These graphs shows the throughput when running a specified numbers of clients each running "tpc-b" like transaction (3 updates, 1 insert, 1 select) against Derby. Each graphs contains the throughput number when the log files are opened with "rws" and "rwd". The first graph is run on a system where the disk's write cache has been disabled. In the second graph the disk's write cache has been enabled. The graphs are produced on dual AMD Opteron machine running Solaris 10 and Sun JDK 1.5. > Change file option for syncing log file to disk from rws to rwd > --- > > Key: DERBY-2020 > URL: http://issues.apache.org/jira/browse/DERBY-2020 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.3.0.0 >Reporter: Olav Sandstaa > Attachments: disk-cache.png, no-disk-cache.png > > > For writing the transaction log to disk Derby uses a > RandomAccessFile. If it is supported by the JVM, the log files are > opened in "rws" mode making the file system take care of syncing > writes to disk. "rws" mode will ensure that both the data and the file > meta-data is updated for every write to the file. On some operating > systems (e.g. Solaris) this leads to two write operation to the disk > for every write issued by Derby. This is limiting the throughput of > update intensive applications. If we could change the file mode to > "rwd" this could reduce the number of updates to the disk. > I have run some simple tests where I have changed mode from "rws" to > "rwd" for the Derby log file. When running a small numbers of > concurrent client threads the throughput is almost doubled and the > response time is almost halved. I will attach some graphs that show > this when running a given number of concurrent "tpc-b" like clients. These > graphs show the throughput when running with "rws" and "rwd" mode when the > disk's write cache has been enabled and disabled. > I am creating this Jira to have a place where we can collect > information about issues both for and against changing the default > mode for writing to log files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
Change file option for syncing log file to disk from rws to rwd --- Key: DERBY-2020 URL: http://issues.apache.org/jira/browse/DERBY-2020 Project: Derby Issue Type: Improvement Components: Performance, Store Affects Versions: 10.3.0.0 Reporter: Olav Sandstaa For writing the transaction log to disk Derby uses a RandomAccessFile. If it is supported by the JVM, the log files are opened in "rws" mode making the file system take care of syncing writes to disk. "rws" mode will ensure that both the data and the file meta-data is updated for every write to the file. On some operating systems (e.g. Solaris) this leads to two write operation to the disk for every write issued by Derby. This is limiting the throughput of update intensive applications. If we could change the file mode to "rwd" this could reduce the number of updates to the disk. I have run some simple tests where I have changed mode from "rws" to "rwd" for the Derby log file. When running a small numbers of concurrent client threads the throughput is almost doubled and the response time is almost halved. I will attach some graphs that show this when running a given number of concurrent "tpc-b" like clients. These graphs show the throughput when running with "rws" and "rwd" mode when the disk's write cache has been enabled and disabled. I am creating this Jira to have a place where we can collect information about issues both for and against changing the default mode for writing to log files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1783) Logical error in code for determining mode for opening of log files
[ http://issues.apache.org/jira/browse/DERBY-1783?page=all ]
Olav Sandstaa closed DERBY-1783.
Problem fixed on trunk.
> Logical error in code for determining mode for opening of log files
> ---
>
> Key: DERBY-1783
> URL: http://issues.apache.org/jira/browse/DERBY-1783
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.2.1.0
> Environment: JVM 1.4.2 and later
>Reporter: Olav Sandstaa
> Assigned To: Olav Sandstaa
>Priority: Trivial
> Fix For: 10.3.0.0
>
> Attachments: rwsync.diff
>
>
> There is a logical error in the following function in DirFile4.java
> for determining which mode to use when opening a new log file:
> public StorageRandomAccessFile getRandomAccessFile( String mode) throws
> FileNotFoundException
> {
> // Assume that modes "rws" and "rwd" are not supported.
> if(!rwsOK && "rws".equals( mode) || "rwd".equals( mode))
> mode = "rw";
> return new DirRandomAccessFile4( (File) this, mode);
> } // end of getRandomAccessFile
> The expression in the if test is missing parentheses around the OR
> expression making it return the wrong value for one case. If "rwd"
> mode is requested for the file (and this is supported by the JVM), the
> file is opened with "rw" instead of "rwd".
> NOTE: this bug does not effect any current Derby versions since as far
> as I know "rwd" is never used for log files. I came across it when
> experimenting with using "rwd" for the log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1783) Logical error in code for determining mode for opening of log files
[ http://issues.apache.org/jira/browse/DERBY-1783?page=all ]
Olav Sandstaa resolved DERBY-1783.
--
Resolution: Fixed
Derby Info: (was: [Patch Available])
Thanks for reviewing and committing this patch, Suresh.
I have verified the fix on trunk.
> Logical error in code for determining mode for opening of log files
> ---
>
> Key: DERBY-1783
> URL: http://issues.apache.org/jira/browse/DERBY-1783
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.2.1.0
> Environment: JVM 1.4.2 and later
>Reporter: Olav Sandstaa
> Assigned To: Olav Sandstaa
>Priority: Trivial
> Fix For: 10.3.0.0
>
> Attachments: rwsync.diff
>
>
> There is a logical error in the following function in DirFile4.java
> for determining which mode to use when opening a new log file:
> public StorageRandomAccessFile getRandomAccessFile( String mode) throws
> FileNotFoundException
> {
> // Assume that modes "rws" and "rwd" are not supported.
> if(!rwsOK && "rws".equals( mode) || "rwd".equals( mode))
> mode = "rw";
> return new DirRandomAccessFile4( (File) this, mode);
> } // end of getRandomAccessFile
> The expression in the if test is missing parentheses around the OR
> expression making it return the wrong value for one case. If "rwd"
> mode is requested for the file (and this is supported by the JVM), the
> file is opened with "rw" instead of "rwd".
> NOTE: this bug does not effect any current Derby versions since as far
> as I know "rwd" is never used for log files. I came across it when
> experimenting with using "rwd" for the log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1783) Logical error in code for determining mode for opening of log files
[ http://issues.apache.org/jira/browse/DERBY-1783?page=all ]
Olav Sandstaa updated DERBY-1783:
-
Fix Version/s: 10.3.0.0
Derby Info: [Patch Available]
> Logical error in code for determining mode for opening of log files
> ---
>
> Key: DERBY-1783
> URL: http://issues.apache.org/jira/browse/DERBY-1783
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.2.1.0
> Environment: JVM 1.4.2 and later
>Reporter: Olav Sandstaa
> Assigned To: Olav Sandstaa
>Priority: Trivial
> Fix For: 10.3.0.0
>
> Attachments: rwsync.diff
>
>
> There is a logical error in the following function in DirFile4.java
> for determining which mode to use when opening a new log file:
> public StorageRandomAccessFile getRandomAccessFile( String mode) throws
> FileNotFoundException
> {
> // Assume that modes "rws" and "rwd" are not supported.
> if(!rwsOK && "rws".equals( mode) || "rwd".equals( mode))
> mode = "rw";
> return new DirRandomAccessFile4( (File) this, mode);
> } // end of getRandomAccessFile
> The expression in the if test is missing parentheses around the OR
> expression making it return the wrong value for one case. If "rwd"
> mode is requested for the file (and this is supported by the JVM), the
> file is opened with "rw" instead of "rwd".
> NOTE: this bug does not effect any current Derby versions since as far
> as I know "rwd" is never used for log files. I came across it when
> experimenting with using "rwd" for the log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1783) Logical error in code for determining mode for opening of log files
[ http://issues.apache.org/jira/browse/DERBY-1783?page=all ]
Olav Sandstaa updated DERBY-1783:
-
Attachment: rwsync.diff
Patch that fixes the logical code error by adding parentheses around the OR
clause. In addition one minor fix to the javadoc for the method is done.
The patch touches the following file:
M java/engine/org/apache/derby/impl/io/DirFile4.java
I have run derbyall on Solaris 10 x86 with JVM 1.5 with no failures. The patch
is ready for review and commit.
> Logical error in code for determining mode for opening of log files
> ---
>
> Key: DERBY-1783
> URL: http://issues.apache.org/jira/browse/DERBY-1783
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.2.1.0
> Environment: JVM 1.4.2 and later
>Reporter: Olav Sandstaa
> Assigned To: Olav Sandstaa
>Priority: Trivial
> Fix For: 10.3.0.0
>
> Attachments: rwsync.diff
>
>
> There is a logical error in the following function in DirFile4.java
> for determining which mode to use when opening a new log file:
> public StorageRandomAccessFile getRandomAccessFile( String mode) throws
> FileNotFoundException
> {
> // Assume that modes "rws" and "rwd" are not supported.
> if(!rwsOK && "rws".equals( mode) || "rwd".equals( mode))
> mode = "rw";
> return new DirRandomAccessFile4( (File) this, mode);
> } // end of getRandomAccessFile
> The expression in the if test is missing parentheses around the OR
> expression making it return the wrong value for one case. If "rwd"
> mode is requested for the file (and this is supported by the JVM), the
> file is opened with "rw" instead of "rwd".
> NOTE: this bug does not effect any current Derby versions since as far
> as I know "rwd" is never used for log files. I came across it when
> experimenting with using "rwd" for the log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1783) Logical error in code for determining mode for opening of log files
[ http://issues.apache.org/jira/browse/DERBY-1783?page=all ]
Olav Sandstaa reassigned DERBY-1783:
Assignee: Olav Sandstaa
> Logical error in code for determining mode for opening of log files
> ---
>
> Key: DERBY-1783
> URL: http://issues.apache.org/jira/browse/DERBY-1783
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.2.1.0
> Environment: JVM 1.4.2 and later
>Reporter: Olav Sandstaa
> Assigned To: Olav Sandstaa
>Priority: Trivial
>
> There is a logical error in the following function in DirFile4.java
> for determining which mode to use when opening a new log file:
> public StorageRandomAccessFile getRandomAccessFile( String mode) throws
> FileNotFoundException
> {
> // Assume that modes "rws" and "rwd" are not supported.
> if(!rwsOK && "rws".equals( mode) || "rwd".equals( mode))
> mode = "rw";
> return new DirRandomAccessFile4( (File) this, mode);
> } // end of getRandomAccessFile
> The expression in the if test is missing parentheses around the OR
> expression making it return the wrong value for one case. If "rwd"
> mode is requested for the file (and this is supported by the JVM), the
> file is opened with "rw" instead of "rwd".
> NOTE: this bug does not effect any current Derby versions since as far
> as I know "rwd" is never used for log files. I came across it when
> experimenting with using "rwd" for the log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1783) Logical error in code for determining mode for opening of log files
Logical error in code for determining mode for opening of log files
---
Key: DERBY-1783
URL: http://issues.apache.org/jira/browse/DERBY-1783
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.2.1.0
Environment: JVM 1.4.2 and later
Reporter: Olav Sandstaa
Priority: Trivial
There is a logical error in the following function in DirFile4.java
for determining which mode to use when opening a new log file:
public StorageRandomAccessFile getRandomAccessFile( String mode) throws
FileNotFoundException
{
// Assume that modes "rws" and "rwd" are not supported.
if(!rwsOK && "rws".equals( mode) || "rwd".equals( mode))
mode = "rw";
return new DirRandomAccessFile4( (File) this, mode);
} // end of getRandomAccessFile
The expression in the if test is missing parentheses around the OR
expression making it return the wrong value for one case. If "rwd"
mode is requested for the file (and this is supported by the JVM), the
file is opened with "rw" instead of "rwd".
NOTE: this bug does not effect any current Derby versions since as far
as I know "rwd" is never used for log files. I came across it when
experimenting with using "rwd" for the log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=all ] Olav Sandstaa closed DERBY-1399. Resolution: Fixed Fixed as part of DERBY-1459. > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.2.0.0 > Environment: Sun JDK 1.6 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa >Priority: Minor > Attachments: autoload.diff > > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=all ] Olav Sandstaa updated DERBY-1399: - Derby Info: (was: [Patch Available]) This patch was never used since autoloading was improved (see DERBY1459) to handle the situation which created problems for the DerbyNetAutoStart thest. > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.2.0.0 > Environment: Sun JDK 1.6 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa >Priority: Minor > Attachments: autoload.diff > > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12427852 ] Olav Sandstaa commented on DERBY-1399: -- DerbyNetAutoStart runs without problems after DERBY-1459 was fixed. The patch is not needed anymore. I agree that we can uncheck patch available. I will also close the Jira issue since it is no longer an issue. > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.2.0.0 > Environment: Sun JDK 1.6 >Reporter: Olav Sandstaa > Assigned To: Olav Sandstaa >Priority: Minor > Attachments: autoload.diff > > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
[ http://issues.apache.org/jira/browse/DERBY-1438?page=all ] Olav Sandstaa closed DERBY-1438. I have verified that SQLException.toString() writes the same text in both network client and embedded driver. Thanks for fixing this, David! > Text written by SQLException.toString differs between client and embedded > driver > > > Key: DERBY-1438 > URL: http://issues.apache.org/jira/browse/DERBY-1438 > Project: Derby > Issue Type: Improvement > Components: JDBC, Newcomer >Affects Versions: 10.2.0.0 > Environment: Sun JDK 1.5 >Reporter: Olav Sandstaa > Assigned To: David Van Couvering >Priority: Trivial > Fix For: 10.2.0.0 > > Attachments: DERBY-1438-rev2.diff, DERBY-1438.diff > > > The first part of the string written by SQLExeption.toString() differs > between the Derby client driver and the embedded driver. The embedded > driver writes: >SQL Exception: Table/View 'DERBYDB' does not exist. > while the client driver writes: >java.sql.SQLException: Table/View 'DERBYDB' does not exist. > It would be good if we changed this so the same text is written by > both drivers. This reduces the difference seen when changing between > client and embedded Derby and it make it possible to reduce the amount > of sed-ing or the number of master file variants for some tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-253) Client should throw not implemented exception for depricated setUnicodeStream/getUnicodeStream
[ http://issues.apache.org/jira/browse/DERBY-253?page=comments#action_12420864 ] Olav Sandstaa commented on DERBY-253: - Knut Anders, thanks for the proposal to release notes. This looks very good. > Client should throw not implemented exception for depricated > setUnicodeStream/getUnicodeStream > -- > > Key: DERBY-253 > URL: http://issues.apache.org/jira/browse/DERBY-253 > Project: Derby > Type: Bug > Components: Network Client, JDBC > Versions: 10.1.1.0 > Reporter: Kathey Marsden > Assignee: Olav Sandstaa > Fix For: 10.2.0.0 > Attachments: derby253.diff > > setUnicodeStream and getUnicodeStream are deprecated API's > Network client > PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream() should > throw not implemented exceptions rather than trying to handle these calls. > Note: The current client implementation of setUnicodeStream() and > getUnicodeStream() are broken and can cause unexpected errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-253) Client should throw not implemented exception for depricated setUnicodeStream/getUnicodeStream
[ http://issues.apache.org/jira/browse/DERBY-253?page=all ] Olav Sandstaa resolved DERBY-253: - Resolution: Fixed Verified that the patch is in. Thanks for commiting it, Knut Anders! > Client should throw not implemented exception for depricated > setUnicodeStream/getUnicodeStream > -- > > Key: DERBY-253 > URL: http://issues.apache.org/jira/browse/DERBY-253 > Project: Derby > Type: Bug > Components: Network Client, JDBC > Versions: 10.1.1.0 > Reporter: Kathey Marsden > Assignee: Olav Sandstaa > Fix For: 10.2.0.0 > Attachments: derby253.diff > > setUnicodeStream and getUnicodeStream are deprecated API's > Network client > PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream() should > throw not implemented exceptions rather than trying to handle these calls. > Note: The current client implementation of setUnicodeStream() and > getUnicodeStream() are broken and can cause unexpected errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-253) Client should throw not implemented exception for depricated setUnicodeStream/getUnicodeStream
[ http://issues.apache.org/jira/browse/DERBY-253?page=all ] Olav Sandstaa updated DERBY-253: Derby Info: (was: [Patch Available]) > Client should throw not implemented exception for depricated > setUnicodeStream/getUnicodeStream > -- > > Key: DERBY-253 > URL: http://issues.apache.org/jira/browse/DERBY-253 > Project: Derby > Type: Bug > Components: Network Client, JDBC > Versions: 10.1.1.0 > Reporter: Kathey Marsden > Assignee: Olav Sandstaa > Fix For: 10.2.0.0 > Attachments: derby253.diff > > setUnicodeStream and getUnicodeStream are deprecated API's > Network client > PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream() should > throw not implemented exceptions rather than trying to handle these calls. > Note: The current client implementation of setUnicodeStream() and > getUnicodeStream() are broken and can cause unexpected errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-253) Client should throw not implemented exception for depricated setUnicodeStream/getUnicodeStream
[ http://issues.apache.org/jira/browse/DERBY-253?page=comments#action_12420833 ] Olav Sandstaa commented on DERBY-253: - Thanks for reviewing and committing this patch, Knut Anders! Since this patch removes functionality from the client driver (although probably broken functionality), is this something that needs a comment in the release notes? > Client should throw not implemented exception for depricated > setUnicodeStream/getUnicodeStream > -- > > Key: DERBY-253 > URL: http://issues.apache.org/jira/browse/DERBY-253 > Project: Derby > Type: Bug > Components: Network Client, JDBC > Versions: 10.1.1.0 > Reporter: Kathey Marsden > Assignee: Olav Sandstaa > Fix For: 10.2.0.0 > Attachments: derby253.diff > > setUnicodeStream and getUnicodeStream are deprecated API's > Network client > PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream() should > throw not implemented exceptions rather than trying to handle these calls. > Note: The current client implementation of setUnicodeStream() and > getUnicodeStream() are broken and can cause unexpected errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-253) Client should throw not implemented exception for depricated setUnicodeStream/getUnicodeStream
[ http://issues.apache.org/jira/browse/DERBY-253?page=all ] Olav Sandstaa updated DERBY-253: Derby Info: [Patch Available] > Client should throw not implemented exception for depricated > setUnicodeStream/getUnicodeStream > -- > > Key: DERBY-253 > URL: http://issues.apache.org/jira/browse/DERBY-253 > Project: Derby > Type: Bug > Components: Network Client, JDBC > Versions: 10.1.1.0 > Reporter: Kathey Marsden > Assignee: Olav Sandstaa > Fix For: 10.2.0.0 > Attachments: derby253.diff > > setUnicodeStream and getUnicodeStream are deprecated API's > Network client > PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream() should > throw not implemented exceptions rather than trying to handle these calls. > Note: The current client implementation of setUnicodeStream() and > getUnicodeStream() are broken and can cause unexpected errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-253) Client should throw not implemented exception for depricated setUnicodeStream/getUnicodeStream
[ http://issues.apache.org/jira/browse/DERBY-253?page=all ] Olav Sandstaa updated DERBY-253: Attachment: derby253.diff This patch replaces the existing implementation of setUnicodeStream and getUnicodeStream in the client driver to just throw a SQL exception with SQL state equal to feature not implemented. The following files are changed: M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/parameterMapping.out M java/client/org/apache/derby/client/am/PreparedStatement.java M java/client/org/apache/derby/client/am/ResultSet.java The patch is ready for review and commit. > Client should throw not implemented exception for depricated > setUnicodeStream/getUnicodeStream > -- > > Key: DERBY-253 > URL: http://issues.apache.org/jira/browse/DERBY-253 > Project: Derby > Type: Bug > Components: Network Client, JDBC > Versions: 10.1.1.0 > Reporter: Kathey Marsden > Assignee: Olav Sandstaa > Fix For: 10.2.0.0 > Attachments: derby253.diff > > setUnicodeStream and getUnicodeStream are deprecated API's > Network client > PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream() should > throw not implemented exceptions rather than trying to handle these calls. > Note: The current client implementation of setUnicodeStream() and > getUnicodeStream() are broken and can cause unexpected errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1427) sysinfo does not write Java SE and JDBC version when running under JDK 1.6
[ http://issues.apache.org/jira/browse/DERBY-1427?page=all ] Olav Sandstaa closed DERBY-1427: Verified that sysinfo now produces the correct Java and JDBC version info when running with jdk 1.6. Thanks for fixing this, Knut Anders. > sysinfo does not write Java SE and JDBC version when running under JDK 1.6 > -- > > Key: DERBY-1427 > URL: http://issues.apache.org/jira/browse/DERBY-1427 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Knut Anders Hatlen > Priority: Minor > Fix For: 10.2.0.0 > Attachments: derby-1427-v1.diff, derby-1427-v1.stat > > When running sysinfo with jdk 1.6 information about which Java SE and JDBC > versions that is supported is missing in the output. The following is written: > - Derby Information > JRE - JDBC: ?-? > The complete output from sysinfo: > -- Java Information -- > Java Version:1.6.0-beta2 > Java Vendor: Sun Microsystems Inc. > Java home: /usr/local/java/jdk1.6.0_b86/jre > Java classpath: jars/sane/derby.jar > OS name: SunOS > OS architecture: x86 > OS version: 5.10 > Java user name: os136802 > Java user home: /home/os136802 > Java user dir: /home/os136802/derby/develop/jdk16/trunk > java.specification.name: Java Platform API Specification > java.specification.version: 1.6 > - Derby Information > JRE - JDBC: ?-? > [/home/os136802/derby/develop/jdk16/trunk/jars/sane/derby.jar] 10.2.0.4 alpha > - (415258M) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] > version: 10.2.0.4 alpha - (415258M) > Found support for locale: [es] > version: 10.2.0.4 alpha - (415258M) > Found support for locale: [fr] > version: 10.2.0.4 alpha - (415258M) > Found support for locale: [it] > version: 10.2.0.4 alpha - (415258M) > Found support for locale: [ja_JP] > version: 10.2.0.4 alpha - (415258M) > Found support for locale: [ko_KR] > version: 10.2.0.4 alpha - (415258M) > Found support for locale: [pt_BR] > version: 10.2.0.4 alpha - (415258M) > Found support for locale: [zh_CN] > version: 10.2.0.4 alpha - (415258M) > Found support for locale: [zh_TW] > version: 10.2.0.4 alpha - (415258M) > -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
[
http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417334 ]
Olav Sandstaa commented on DERBY-1438:
--
Personally, I prefer the text written by the embedded driver ("SQL Exception:")
over the text written by the client driver ("java.sql.Exception:"), but with
the introduction of the SQL exception hierarchy in Java SE 6 it might be better
to use the exact exception name (e.g.
"java.sql.IamSorryThisShouldNotHappenTodayException") which is what I think you
get if you call SQLException.toString() and running with jdk 1.6.
> Text written by SQLException.toString differs between client and embedded
> driver
>
>
> Key: DERBY-1438
> URL: http://issues.apache.org/jira/browse/DERBY-1438
> Project: Derby
> Type: Improvement
> Components: JDBC, Newcomer
> Versions: 10.2.0.0
> Environment: Sun JDK 1.5
> Reporter: Olav Sandstaa
> Assignee: David Van Couvering
> Priority: Trivial
>
> The first part of the string written by SQLExeption.toString() differs
> between the Derby client driver and the embedded driver. The embedded
> driver writes:
>SQL Exception: Table/View 'DERBYDB' does not exist.
> while the client driver writes:
>java.sql.SQLException: Table/View 'DERBYDB' does not exist.
> It would be good if we changed this so the same text is written by
> both drivers. This reduces the difference seen when changing between
> client and embedded Derby and it make it possible to reduce the amount
> of sed-ing or the number of master file variants for some tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1440) ij running with client driver and jdk 1.6 omits chained exceptions in error messages
ij running with client driver and jdk 1.6 omits chained exceptions in error
messages
Key: DERBY-1440
URL: http://issues.apache.org/jira/browse/DERBY-1440
Project: Derby
Type: Bug
Components: Tools, JDBC, Network Client
Versions: 10.2.0.0
Environment: Sun JDK 1.6
Reporter: Olav Sandstaa
Priority: Minor
When running some SQL queries through ij that fails it seems like some
information about chained exceptions is not presented to the user when
running with the client driver and jdk 1.6.
One example SQL that fails (taken from the ieptests.sql):
=
ij> call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('inventory', 'ORDERTABLE' ,
'extinout/order.dat', null, null, null) ;
When running this in ij the following error message is produced:
Java 1.6 Embedded driver:
=
ERROR 38000: The exception 'java.sql.SQLSyntaxErrorException: Schema
'inventory' does not exist' was thrown while evaluating an expression.
ERROR 42Y07: Schema 'inventory' does not exist
Java 1.5 Client driver:
===
ERROR 38000: The exception 'SQL Exception: Schema 'inventory' does not
exist' was thrown while evaluating an expression. SQLSTATE: 42Y07:
Schema 'inventory' does not exist
Java 1.6 Client driver:
===
ERROR 38000: The exception 'java.sql.SQLSyntaxErrorException: Schema
'inventory' does not exist' was thrown while evaluating an expression.
The bug (or difference) here is that the client driver when running
with jdk 1.6 does not print the chained exception and SQL state.
It would be nice to have the same information in the output as what is
written by the embedded driver (or client driver running with jdk
1.5).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
Text written by SQLException.toString differs between client and embedded driver Key: DERBY-1438 URL: http://issues.apache.org/jira/browse/DERBY-1438 Project: Derby Type: Improvement Components: JDBC, Newcomer Versions: 10.2.0.0 Environment: Sun JDK 1.5 Reporter: Olav Sandstaa Priority: Trivial The first part of the string written by SQLExeption.toString() differs between the Derby client driver and the embedded driver. The embedded driver writes: SQL Exception: Table/View 'DERBYDB' does not exist. while the client driver writes: java.sql.SQLException: Table/View 'DERBYDB' does not exist. It would be good if we changed this so the same text is written by both drivers. This reduces the difference seen when changing between client and embedded Derby and it make it possible to reduce the amount of sed-ing or the number of master file variants for some tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-955) Get derbyall on jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-955?page=all ] Olav Sandstaa updated DERBY-955: Derby Info: [Patch Available] > Get derbyall on jdk1.6 > -- > > Key: DERBY-955 > URL: http://issues.apache.org/jira/browse/DERBY-955 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Anurag Shekhar > Fix For: 10.2.0.0 > Attachments: bug955_blobclob4BLOB.diff, bug955_derbyall.diff, > bug955_sed2.diff, bug955_sed_SQLException.diff, bug955_sysinfo.diff, > bug955_wireUpJDBC4ClientSuite.diff, bug955_wireUpJDBC4Suite.diff > > This bug is a placeholder for patches which enable derbyall to run on jdk1.6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-955) Get derbyall on jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-955?page=all ] Olav Sandstaa updated DERBY-955: Attachment: bug955_derbyall.diff This patch contains fixes to the following tests that are failing when running derbyall with jdk 1.6: * derbynetclientmats: tools/ieptests.sql -updated master file for jdk16 * derbynetclientmats: jdbcapi/parameterMappint.java -REMOVED jdk16 specific master file * derbynetclientmats: jdbcapi/checkDataSource30.java -updated checkDataSource30.java and checkDataSource.java to produce output that is the same when running with jdk15 and jdk16 -updated master files to reflect changes in output * derbynetmats: tools/ieptests.sql -updated master file for jdk16 svn status reports: M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/checkDataSource30.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/checkDataSource.java M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk16/ieptests.out M java/testing/org/apache/derbyTesting/functionTests/master/checkDataSource30.out D java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/parameterMapping.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/ieptests.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/checkDataSource.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/checkDataSource30.out M java/testing/org/apache/derbyTesting/functionTests/master/checkDataSource.out Note: one master file has been removed. I have run derbyall with jdk 1.5 and 1.6. The patch is ready for review and commit. > Get derbyall on jdk1.6 > -- > > Key: DERBY-955 > URL: http://issues.apache.org/jira/browse/DERBY-955 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Anurag Shekhar > Fix For: 10.2.0.0 > Attachments: bug955_blobclob4BLOB.diff, bug955_derbyall.diff, > bug955_sed2.diff, bug955_sed_SQLException.diff, bug955_sysinfo.diff, > bug955_wireUpJDBC4ClientSuite.diff, bug955_wireUpJDBC4Suite.diff > > This bug is a placeholder for patches which enable derbyall to run on jdk1.6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1427) sysinfo does not write Java SE and JDBC version when running under JDK 1.6
sysinfo does not write Java SE and JDBC version when running under JDK 1.6 -- Key: DERBY-1427 URL: http://issues.apache.org/jira/browse/DERBY-1427 Project: Derby Type: Bug Components: Tools Versions: 10.2.0.0 Environment: Sun JDK 1.6 Reporter: Olav Sandstaa Priority: Minor When running sysinfo with jdk 1.6 information about which Java SE and JDBC versions that is supported is missing in the output. The following is written: - Derby Information JRE - JDBC: ?-? The complete output from sysinfo: -- Java Information -- Java Version:1.6.0-beta2 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.6.0_b86/jre Java classpath: jars/sane/derby.jar OS name: SunOS OS architecture: x86 OS version: 5.10 Java user name: os136802 Java user home: /home/os136802 Java user dir: /home/os136802/derby/develop/jdk16/trunk java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: ?-? [/home/os136802/derby/develop/jdk16/trunk/jars/sane/derby.jar] 10.2.0.4 alpha - (415258M) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.0.4 alpha - (415258M) Found support for locale: [es] version: 10.2.0.4 alpha - (415258M) Found support for locale: [fr] version: 10.2.0.4 alpha - (415258M) Found support for locale: [it] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ja_JP] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ko_KR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [pt_BR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_CN] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_TW] version: 10.2.0.4 alpha - (415258M) -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416361 ] Olav Sandstaa commented on DERBY-1399: -- Rick, The failure you see is not related to neither autoloading nor my patch. This problem is reported separately in DERBY-803 and also seen on other platforms than JDK 1.6. My patch did not intend to fix this problem. I have not seen this problem when I run this test. > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Attachments: autoload.diff > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416359 ] Olav Sandstaa commented on DERBY-1399: -- Comments to Kathey's concerns about this patch (or rather the change introduced in DERBY-930): Autoloading of JDBC drivers is a new feature required by JDBC4. In addition to the support for autoloading added to JDBC4 in DERBY-930, the main change is in how new JVMs confirming to Java SE 1.6 treat JDBC4 drivers. So this test change has just as much with adjusting to new behavior in how JVMs loads drivers as it has to do with the changes added to Derby in DERBY-930. I have raised my opinion about support for autoloading of JDBC drivers in a different mail thread (personally I do not like automagic things to happen behind my back even if it is considered "ease of development"), see: http://www.nabble.com/Autoloading-of-JDBC-drivers-considered-harmful--t1689676.html) Still, autoloading will be a documented and supported feature in Derby 10.2 (at least it seems so) and in Java SE 1.6, and (to quote from one of the emails in this email thread) "Thus this is fully documented behavior that any application developer must understand." So as long as the embedded Derby driver is loading the Derby engine and in some cases also the network server, autoloading of the embedded JDBC driver may require applications (and Derby tests) to take this into account when upgrading to a 1.6. JVM. This is basically what the patch I have suggested do. There could have been other solutions to this problem by doing changes to Derby. For instance splitting loading of the embedded driver and booting of the Derby engine and starting of the network server. Even if we decided to do this, this test had to be changed in one way or the other in order to get the network server started (it is now started by setting the property derby.drda.startNetworkServer=true before the embedded driver is loaded). I think splitting of driver loading and booting of the engine would be a good thing to implement, but right now I do not have the time to take on this task. My itch right now is to get this test to run with JDK 1.6 and the change is basically to take into account the new behavior that any 1.6 JVM will have. > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Attachments: autoload.diff > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=all ] Olav Sandstaa updated DERBY-1399: - Derby Info: [Patch Available] > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Attachments: autoload.diff > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=all ] Olav Sandstaa updated DERBY-1399: - Attachment: autoload.diff This patch fixes the problem with the embedded driver being autoloaded before all Derby properties have been defined by explicitly unloading the embedded driver in the start of each sub test. I have run derbyall on Sun JDK 1.5 and 1.6 with only the usual tests failing. svn status reports: M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/DerbyNetAutoStart.java The patch is ready for review and commit. > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Attachments: autoload.diff > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416155 ] Olav Sandstaa commented on DERBY-1399: -- Bryan, thanks for commenting on this issue. The call to TestUtil.loadDriver() needs to be in the test. This method loads the Derby client driver (or the JCC driver when running in the DerbyNet framework). The client driver is used in the test to establish connections to the network server. Without explicitly loading a client driver the test will fail with "No suitable driver" when attempting to connect (at least when running with a pre JDK 1.6 VM). The DerbyNetAutoStart test loads both a client driver (Derby client driver or JCC) and the embedded driver (with or without starting the network server). > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416036 ] Olav Sandstaa commented on DERBY-1399: -- This problem is similar to the problem that caused the NIST tests to fail when running with JDK 1.6 (see DERBY-1379). The DerbyNetAutoStart test does the following during start up: 1. Explicitly load the DerbyNetClient by calling TestUtil.loadDriver(). Due to JDBC driver autoloading, this will also load the embedded JDBC driver and the Derby engine when running with JDK 1.6. 2. Set some properties for the embedded driver. In the first test case this property is: derby.drda.startNetworkServer=true to make the network server start as part of loading the embedded driver. 3. Explicitly load the embedded driver. But since the driver and engine are already loaded, not much is done here. As a consequence the properties set does not take effect, and the network server is not started. This makes the test fail. I plan to fix this problem by explicitly attempt to unload the embedded driver and engine in the start of each individual subtest. (This is already done after each sub test has run, but this does not help the first subtest). > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=all ] Olav Sandstaa reassigned DERBY-1399: Assign To: Olav Sandstaa > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading --- Key: DERBY-1399 URL: http://issues.apache.org/jira/browse/DERBY-1399 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Environment: Sun JDK 1.6 Reporter: Olav Sandstaa Priority: Minor DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and DerbyClient frameworks with the following error: Starting test case 1. Could not access database through the network server. java.net.ConnectException : Error connecting to server localhost on port 152 7 with message Connection refused. Starting test case 2. Could not access database through the network server. java.net.ConnectException : Error connecting to server localhost on port 314 15 with message Connection refused. Starting test case 3. Starting test case 4. Starting test case 5. FAILED. This test seems to have failed consistently since JDBC4 driver autoloading was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1379?page=all ] Olav Sandstaa closed DERBY-1379: Verified that the NIST suite runs successfully as part of derbyall with jdk 1.6. > NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading > --- > > Key: DERBY-1379 > URL: http://issues.apache.org/jira/browse/DERBY-1379 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: autoload.diff > > When running derbyall on jdk16 the Nist tests fails with the following > exception: > java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read) > The tests started to fail after autoloading of JDBC drivers was added to the > embedded driver (see DERBY-930). > To reproduce the problem you need (a) to run from jar files (not class files) > and (b) have the DB2 driver in the class path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1379?page=all ] Olav Sandstaa resolved DERBY-1379: -- Fix Version: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Fix checked on trunk by Rick Hillegas (svn version 412859). > NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading > --- > > Key: DERBY-1379 > URL: http://issues.apache.org/jira/browse/DERBY-1379 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: autoload.diff > > When running derbyall on jdk16 the Nist tests fails with the following > exception: > java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read) > The tests started to fail after autoloading of JDBC drivers was added to the > embedded driver (see DERBY-930). > To reproduce the problem you need (a) to run from jar files (not class files) > and (b) have the DB2 driver in the class path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1379?page=all ] Olav Sandstaa updated DERBY-1379: - Derby Info: [Patch Available] > NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading > --- > > Key: DERBY-1379 > URL: http://issues.apache.org/jira/browse/DERBY-1379 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Attachments: autoload.diff > > When running derbyall on jdk16 the Nist tests fails with the following > exception: > java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read) > The tests started to fail after autoloading of JDBC drivers was added to the > embedded driver (see DERBY-930). > To reproduce the problem you need (a) to run from jar files (not class files) > and (b) have the DB2 driver in the class path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1379?page=all ] Olav Sandstaa updated DERBY-1379: - Attachment: autoload.diff This patch solves the problem with running the Nist tests under jdk 1.6 by unloading the embedded driver before the nist suite is started. This is implemented in the RunList.runSuites method in the test harness. Before a new test suite is started and the suite is defined to run as part of the same JVM (useprocess=false) the embedded driver and Derby engine is unloaded. The purpose of this is that when the suite start running it will (re-)load an embedded driver that will use the properties defined by the suite (in the case of the Nist test the problem was that defined derby.system.home was not used). The patch is ready for review and commit. I would like to get feedback on: 1. The selected approach for solving this problem (by explicitly unload the embedded driver). 2. If the code for unload the driver is included in the test harness on the most appropriate place. svn status reports: M java/testing/org/apache/derbyTesting/functionTests/harness/RunList.java Derbyall has been run with jdk1.5 and jdk1.6 on Solaris 10. The unloading and reloading of the driver does not seem to make any other test fail. If there are no objections to the selected approach for solving this problem, the patch is ready for being committed. > NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading > --- > > Key: DERBY-1379 > URL: http://issues.apache.org/jira/browse/DERBY-1379 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Attachments: autoload.diff > > When running derbyall on jdk16 the Nist tests fails with the following > exception: > java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read) > The tests started to fail after autoloading of JDBC drivers was added to the > embedded driver (see DERBY-930). > To reproduce the problem you need (a) to run from jar files (not class files) > and (b) have the DB2 driver in the class path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1379?page=comments#action_12414952 ] Olav Sandstaa commented on DERBY-1379: -- An overview of some of the suggestions that has been proposed for fixing this issue: * Remove the support for autoloading of the embedded driver (Yes, Rick and the JDBC4 expert group have already said no to this, but I still think there are situations where automagic loading of the drivers is a bad idea) * Change the test harness so that derby.system.home is set to a value that is OK for all tests suites (running with useprocess=false) early during initialization (before touching any JDBC driver code) * Change the RunSuite(?) code so that it unloads the embedded driver and the engine as part of the start up (to get rid of the autoloaded embedded driver) * Change the "security manager" properties for the Nist tests to avoid the security exception when the VM tries to get the canonical path for the working directory. * Split the loading of the embedded driver and booting the engine. When the driver is (auto)-loaded only the driver is loaded. The Derby engine is booted when the first connection is created. > NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading > --- > > Key: DERBY-1379 > URL: http://issues.apache.org/jira/browse/DERBY-1379 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Priority: Minor > > When running derbyall on jdk16 the Nist tests fails with the following > exception: > java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read) > The tests started to fail after autoloading of JDBC drivers was added to the > embedded driver (see DERBY-930). > To reproduce the problem you need (a) to run from jar files (not class files) > and (b) have the DB2 driver in the class path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1379?page=all ] Olav Sandstaa reassigned DERBY-1379: Assign To: Olav Sandstaa > NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading > --- > > Key: DERBY-1379 > URL: http://issues.apache.org/jira/browse/DERBY-1379 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > > When running derbyall on jdk16 the Nist tests fails with the following > exception: > java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read) > The tests started to fail after autoloading of JDBC drivers was added to the > embedded driver (see DERBY-930). > To reproduce the problem you need (a) to run from jar files (not class files) > and (b) have the DB2 driver in the class path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
[
http://issues.apache.org/jira/browse/DERBY-1379?page=comments#action_12414951 ]
Olav Sandstaa commented on DERBY-1379:
--
Updating this jira with the main findings from the email discussions
covering this issue. The complete discussion can be found here:
http://www.nabble.com/jdk16-and-suite-derbyall---128-failures-t1596754.html
The call stack for security exception that causes the Nist tests to fail:
java.security.AccessControlException: access denied
(java.util.PropertyPermission user.dir read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at java.lang.System.getProperty(System.java:652)
at java.io.UnixFileSystem.resolve(UnixFileSystem.java:118)
at java.io.File.getCanonicalPath(File.java:559)
at
org.apache.derby.impl.io.DirStorageFactory.doInit(DirStorageFactory.java:190)
at
org.apache.derby.impl.io.BaseStorageFactory.init(BaseStorageFactory.java:87)
at
org.apache.derby.impl.services.monitor.StorageFactoryService.privGetStorageFactoryInstance(StorageFactoryService.java:201)
at
org.apache.derby.impl.services.monitor.StorageFactoryService.access$400(StorageFactoryService.java:64)
at
org.apache.derby.impl.services.monitor.StorageFactoryService$11.run(StorageFactoryService.java:774)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.derby.impl.services.monitor.StorageFactoryService.getCanonicalServiceName(StorageFactoryService.java:768)
at
org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1537)
at
org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990)
at
org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541)
at
org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1591)
at
org.apache.derby.impl.jdbc.EmbedConnection.(EmbedConnection.java:216)
at
org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:72)
at
org.apache.derby.impl.jdbc.EmbedConnection40.(EmbedConnection40.java:47)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:64)
at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:200)
at java.sql.DriverManager.getConnection(DriverManager.java:548)
at java.sql.DriverManager.getConnection(DriverManager.java:148)
at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:516)
at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:616)
at org.apache.derby.impl.tools.ij.ConnectionEnv.init(ConnectionEnv.java:64)
at org.apache.derby.impl.tools.ij.utilMain.(utilMain.java:176)
at org.apache.derby.impl.tools.ij.utilMain14.(utilMain14.java:51)
at org.apache.derby.impl.tools.ij.Main14.getutilMain(Main14.java:102)
at org.apache.derby.impl.tools.ij.Main.(Main.java:265)
at org.apache.derby.impl.tools.ij.Main14.(Main14.java:68)
at org.apache.derby.impl.tools.ij.Main14.getMain(Main14.java:91)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:189)
at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
at org.apache.derby.tools.ij.main(ij.java:60)
at org.apache.derbyTesting.functionTests.harness.RunIJ.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)
The cause for the Nist test to fail when running with jdk16 is the
introduction of autoloading of the embedded driver combined with the
value that derby.system.home has at the time the embedded driver is
loaded.
When the Nist tests succeeds, derby.system.home contains the name of
the directory where the test should be run
(e.g. /export/home/tmp/derbysuite/nist in my case). derby.system.home
is set by the test harness when it starts each individual test suite.
When the Nist tests fails the embedded driver and the Derby engine is
loaded as part of startup of derbyall. This happens as part of loading
the DB2 driver in the following code in RunList.shouldSkipTest:
if (framework.equals("DerbyNet"))
{
// skip if the derbynet.jar is not in the Classpath
try {
Class.forName("org.apache.derby.drda.NetworkServerControl");
} catch (ClassNotFoundException cnfe) {
driverNotFound = true;
result = true;
}
// skip if the IBM Universal JDBC Driver is not in the Classpath
// note that that driver loads some javax.naming.* classes which may not
// be present at runtime, and thus we need to catch a possible error too
try {
Class.forName("com.ibm.db2.jcc.DB2Driver");
} catch (ClassNotFoundException cnfe) {
driverNotFound = true;
result = true;
} catch (NoClassDefFoundErro
[jira] Created: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading --- Key: DERBY-1379 URL: http://issues.apache.org/jira/browse/DERBY-1379 Project: Derby Type: Bug Components: Tools Versions: 10.2.0.0 Environment: Sun JDK 1.6 Reporter: Olav Sandstaa Priority: Minor When running derbyall on jdk16 the Nist tests fails with the following exception: java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read) The tests started to fail after autoloading of JDBC drivers was added to the embedded driver (see DERBY-930). To reproduce the problem you need (a) to run from jar files (not class files) and (b) have the DB2 driver in the class path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1359) Developers guide: example showing shut down of Derby system should not contain a database name
Developers guide: example showing shut down of Derby system should not contain
a database name
--
Key: DERBY-1359
URL: http://issues.apache.org/jira/browse/DERBY-1359
Project: Derby
Type: Bug
Components: Documentation
Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.0, 10.1.1.1,
10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
Reporter: Olav Sandstaa
Priority: Trivial
In the Developers Guide the chapter "Shutting Down the System" gives the
following command to shut down the Derby system:
DriverManager.getConnection("jdbc:derby:cs;shutdown=true");
This command should not include the name of a database ("cs"). The correct
command should be:
DriverManager.getConnection("jdbc:derby:;shutdown=true");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1214) JDBC4 calls in the Brokered* classes need to be forwarded to more capable classes.
[ http://issues.apache.org/jira/browse/DERBY-1214?page=comments#action_12412350 ] Olav Sandstaa commented on DERBY-1214: -- I have looked at the changes to BrokeredConnection40.java and have only one question/comment. Why does not the createSQLXML() method call notifyException() when an exception is thrown? Otherwise I have no more comments to the patch. ..olav > JDBC4 calls in the Brokered* classes need to be forwarded to more capable > classes. > -- > > Key: DERBY-1214 > URL: http://issues.apache.org/jira/browse/DERBY-1214 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Anurag Shekhar > Attachments: derby-1214.diff > > Currently, the JDBC4 methods in the Brokered* classes raise > SQLFeatureNotSupported. They should, where appropriate, forward their calls > to more capable classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa closed DERBY-1090: > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: brokeredlogical1090.diff, client1090_patch1.diff, > client1090_patch2.diff, embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa resolved DERBY-1090: -- Resolution: Fixed > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: brokeredlogical1090.diff, client1090_patch1.diff, > client1090_patch2.diff, embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Derby Info: (was: [Patch Available]) > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: brokeredlogical1090.diff, client1090_patch1.diff, > client1090_patch2.diff, embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Attachment: brokeredlogical1090.diff This patch (brokeredlogical1090.diff) implemets support for Connection.isValid for pooled and XA connections. Testing of isValid for pooled and XA connections is implemented in the jdbc4/ConnectionTest.junit. This test is currently not part of either the jdbc4 suite or derbyall. svn status reports: M java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection40.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/ConnectionTest.java M java/client/org/apache/derby/client/am/LogicalConnection40.java I have run the jdbc4/ConnectionTest.junig, the JDBC4 test suite and derbyall with the patch. Only failure was in tools/derbyrunjartest.java. The patch can be reviewed and committed. > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: brokeredlogical1090.diff, client1090_patch1.diff, > client1090_patch2.diff, embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Derby Info: [Patch Available] > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: client1090_patch1.diff, client1090_patch2.diff, > embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Attachment: client1090_patch2.diff This patch (client1090_patch2.diff) addresses the problem of Connection.isValid() hanging infinite if the server is either "hanging" or not sending a reply. The reason for the client to hang in these situations is that blocking read (and write) is used for receiving replies from the Derby network server. To avoid the client hanging infinite in the blocking read when the caller has specified a timeout to isValid() we set a maximum timeout value on the socket (by using java.net.socket.setSoTimeout()) before the query is sent to the server. Thus, if the server does not respond within the specified timeout period the blocking read will return with an exception. If this exception is thrown, isValid will return false for this connection. The timeout on the socket is reset to whatever value it had before the call to isValid. Thus, this socket timeout should only influence on the query issued by the isValid code. The implementation has been tested by setting a very low timeout value and introducing a delay in the network server. svn status reports: M java/client/org/apache/derby/client/net/NetAgent.java M java/client/org/apache/derby/client/net/NetConnection40.java I have run the JDBC4 tests and derbyall with the patch. Only failure was in tools/derbyrunjartest.java. The patch can be reviewed and committed. > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: client1090_patch1.diff, client1090_patch2.diff, > embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=comments#action_12376267 ] Olav Sandstaa commented on DERBY-1090: -- The first implementation of Connection.isValid() for the client driver handles most failuire situations. One situation that is not handled is if the server "hangs" and the client does not receive a reply. The application will be hanging "forever" in the isValid() call due to the blocking read on the socket even if a timeout value has been specified. I plan to submit a fix to this problem by setting a timeout on the socket before the read is called on the socket (using java.net.socket.setSoTimeout). One potential problem with using socket.setSoTimeout is that its implementation is platform dependent. Some operating systems might not support the timeout value and block forever on socket operations even if a timeout is set. I would appreciate to hear if anybody has better or alternative solutions on how to handle the problem with blocking socket read and hanging server. > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: client1090_patch1.diff, embedded1090-isclosed.diff, > embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Derby Info: (was: [Patch Available]) Dyre and Rick, thanks for reviewing and committing the patch. > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: client1090_patch1.diff, embedded1090-isclosed.diff, > embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1238) Add vacuous implementations for Connection.createStruct() and Connection.createArray()
[ http://issues.apache.org/jira/browse/DERBY-1238?page=all ] Olav Sandstaa reassigned DERBY-1238: Assign To: Olav Sandstaa > Add vacuous implementations for Connection.createStruct() and > Connection.createArray() > -- > > Key: DERBY-1238 > URL: http://issues.apache.org/jira/browse/DERBY-1238 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Olav Sandstaa > Fix For: 10.2.0.0 > > An upcoming rev of jdk16 will require that we add vacuous implementations of > the following new methods in Connection. We can just raise > SQLFeatureNotSupported because Derby does not support Array or Struct types: > Array createArray() throws SQLException; > Struct createStruct() throws SQLException; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Derby Info: [Patch Available] > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: client1090_patch1.diff, embedded1090-isclosed.diff, > embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ]
Olav Sandstaa updated DERBY-1090:
-
Attachment: client1090_patch1.diff
This patch (client1090_patch1.diff) implements the Connection.isValid for the
network client. The connection is valid if (a) it is not closed (checked
isClosed()) and (b) a simple query ("VALUES (1)") is executed successfully. Any
exception thrown by the query execution is treated as if the connection is not
valid.
If a timeout is specified this is handled by setting a query timeout for
executing the query (queryTimeout() is used).
The implementation handles most failure situations, with the exception of a
hanging server that is not returning any reply to the client. I plan to submit
a fix for this in a separte patch.
The isValid() call is tested for the following scenarios:
-illegal parameter values (negative timeout)
-no timeout value
-with a timeout specified
-on a connection to a database that has been shutdown
-on a connection to a network server that has been stopped
svn status reports:
M
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestConnectionMethods.java
M java/client/org/apache/derby/client/net/NetConnection40.java
I have run the JDBC4 tests and derbyall with the patch. Only failure was in
tools/derbyrunjartest.java.
The patch can be reviewed and committed.
> Implement Connection.isValid as defined by JDBC4
>
>
> Key: DERBY-1090
> URL: http://issues.apache.org/jira/browse/DERBY-1090
> Project: Derby
> Type: Sub-task
> Components: JDBC
> Reporter: Olav Sandstaa
> Assignee: Olav Sandstaa
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: client1090_patch1.diff, embedded1090-isclosed.diff,
> embedded1090-query.diff
>
> The Javadoc for JDBC4 says this about Connection.isValid:
> boolean isValid(int timeout) throws SQLException
> Returns true if the connection has not been closed and is still valid. The
> driver shall submit a query on the connection or use some other mechanism
> that positively verifies the connection is still valid when this method is
> called.
> The query submitted by the driver to validate the connection shall be
> executed in the context of the current transaction.
> Parameters: timeout - - The time in seconds to wait for the database
> operation used to validate the connection to complete. If the timeout period
> expires before the operation completes, this method returns false. A value of
> 0 indicates a timeout is not applied to the database operation.
> Returns: true if the connection is valid, false otherwise
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Other Info: (was: [Patch available]) > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Other Info: [Patch available] > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=all ] Olav Sandstaa updated DERBY-1090: - Attachment: embedded1090-isclosed.diff This patch (embedded1090-isclosed.diff) implementations Connection.isValid() for the embedded driver by verifying that the connection is not closed (by calling isClosed()). If the connection is closed, isValid returns false, otherwise it returns true. The timeout defined as a parameter to isValid is not used. Compared to the previous patch I sent a few days ago (embedded1090-query.diff), this patch does not run any query against Derby to validate the connection. My proposal (also based on suggestions from Dan) is that we only check for isClosed() in the embedded driver. I have not experienced any situation where isClosed returned false and the query failed. If we later discover situations where the connection is not "valid" even if isValid returns true, we can add a query as done in my first patch to isValid. Testing: The patch extends the TestConnectionMethods.java test with test for isValid in the following cases: -wrong parameter values (negative timeout) -isValid with no timeout -isValid with a specified timeout -isValid on a connection that is closed -isValid on a "open connection" to a database that is shutdown svn status reports: M java/engine/org/apache/derby/impl/jdbc/EmbedConnection40.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestConnectionMethods.java I have run the JDBC4 tests using Java 1.6 and derbyall using Java 1.5 under Solaris 10 x86. Only errors seen in the regression test was reported (runtimeinfo failed in derbynetmats). The patch is complete for the embedded driver and can be reviewed and committed. > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: embedded1090-isclosed.diff, embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1090) Implement Connection.isValid as defined by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1090?page=comments#action_12371422 ] Olav Sandstaa commented on DERBY-1090: -- Hi, David. The main purpose of sending in the patch was to get opinions from more people on what would be the best alternative solution to check if a connection is valid in the embedded driver. The current alternatives are: a) check if connection is not closed followed by a simple query against the database (this is implemented by the patch I submitted yesterday) b) just check that the connection is not closed (I plan to submit an alternative patch for this soon) Dan has suggested that checking for isClosed could be sufficient in the embedded version. It would be good to hear if other have opinions about this. If I do not get other suggestions I will probably propose that the next patch (checking only for isClosed) being reviewed and commited. > Implement Connection.isValid as defined by JDBC4 > > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > Attachments: embedded1090-query.diff > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The > driver shall submit a query on the connection or use some other mechanism > that positively verifies the connection is still valid when this method is > called. > The query submitted by the driver to validate the connection shall be > executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database > operation used to validate the connection to complete. If the timeout period > expires before the operation completes, this method returns false. A value of > 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1133) Split jdbc4 tests so that the suite can be run independently under the embedded and DerbyNetClients like other Derby test suites
[ http://issues.apache.org/jira/browse/DERBY-1133?page=comments#action_12371408 ] Olav Sandstaa commented on DERBY-1133: -- Hi Rick, thanks for fixing up the jdbc4 suite to make it possible to run using the standard test frameworks. Some minor comments to your patch: 1. I think the StartTestConnection.java test could be removed from the test suite. This test tested that the previously used metods for creating a connection to the database worked. With your change to get the connections using ij.startJBMS, this test basically runs connection.close. 2. The following files can be removed (if you do 1.): jdbc4/StartTestConnection.java jdbc4/TestConnection.java 3. A tiny comment: the files for the jdbc4 test code was basically TAB free before your check-in. > Split jdbc4 tests so that the suite can be run independently under the > embedded and DerbyNetClients like other Derby test suites > > > Key: DERBY-1133 > URL: http://issues.apache.org/jira/browse/DERBY-1133 > Project: Derby > Type: Improvement > Components: Test > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Attachments: bug1133.diff, bug1133_rev2.diff > > Right now the jdbc4 suite runs under the DerbyNetClient. However, under the > covers, the tests also run themselves against the embedded client. We should > fix these tests so that the whole suite can run just under DerbyNetClient or > just under the embedded client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
