[jira] Commented: (DERBY-3299) Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns.
[ https://issues.apache.org/jira/browse/DERBY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569200#action_12569200 ] Kristian Waagan commented on DERBY-3299: I took 'd3299_caUtilMethods_v1.patch' out for a spin. I haven't reviewed the code, but noticed that the JavaDoc for DDLSingleTableConstantAction.executeConglomReplacement uses an incorrect parameter name. I don't have any comments on the approach and code otherwise, I was just a little curious and had a quick look :) Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns. --- Key: DERBY-3299 URL: https://issues.apache.org/jira/browse/DERBY-3299 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: A B Assignee: A B Priority: Minor Attachments: case_2.sql, d3299_caUtilMethods_v1.patch, d3299_createIxAction_v1.patch, d3299_dropSharedConglom_v1.patch, d3299_tests_v1.patch, d3299_v1.patch When there are multiple constraints on a single table and the constraints have the same set of columns (in the same order), Derby tries to optimize things by re-using a single backing index for all of the relevant constraints. See the executeConstantAction() method of CreateIndexConstantAction.java (search for duplicate). But there is a bug in Derby where, if one of the constraints is unique and is dropped, the uniqueness attribute of the backing index is not updated accordingly. This means that uniqueness may be incorrectly enforced where it is not required. Take the following example (Case 2 from DERBY-2204): ALTER TABLE NEWORDERS ADD CONSTRAINT NEWORDERS_PK PRIMARY KEY(NO_W_ID, NO_D_ID, NO_O_ID); ALTER TABLE NEWORDERS ADD CONSTRAINT NO_O_FK FOREIGN KEY (NO_W_ID, NO_D_ID, NO_O_ID) REFERENCES ORDERS; For these statements Derby will use a single backing index for both the primary constraint NEWORDERS_PK and the foreign key constraint NO_O_FK. That backing index will be unique because the primary key must itself be unique. If later we drop the primary key: ALTER TABLE NEWORDERS DROP CONSTRAINT NEWORDERS_PK; then the backing index needs to be converted from a unique index to a non-unique index (because a foreign key is not inherently unique). But in Derby the uniqueness attribute remains unchanged, so attempts to insert a duplicate (NO_W_ID, NO_D_ID, NO_O_ID) row into NEWORDERS will fail with error 23505, when it should really succeed. I tried this out on 10.1.3.1 and the same behavior occurs there, so marking Affects versions for everything back to that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen resolved DERBY-3301. --- Resolution: Fixed Fix Version/s: 10.4.0.0 Marking as resolved for 10.4.0.0. This fix should probably be merged to 10.3 too? Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE
[jira] Commented: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569204#action_12569204 ] Knut Anders Hatlen commented on DERBY-3404: --- There was one failure in the JDBC 4 tests with the patch: 1) testAutoCommitFailure(org.apache.derbyTesting.functionTests.tests.jdbc4.TestDbMetaData)junit.framework.AssertionFailedError: autoCommitFailureClosesAllResultSets() returned value which doesn't match actual behaviour. expected:true but was:false at org.apache.derbyTesting.functionTests.tests.jdbc4.TestDbMetaData.testAutoCommitFailure(TestDbMetaData.java:492) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java, d3404-v1.diff, d3404-v1.stat The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3415) 'DataSourceSerializationTestjunit.framework.AssertionFailedError' on 'extin\ClientConnectionPoolDataSource-10_1_3_1.ser' on Windows.
[ https://issues.apache.org/jira/browse/DERBY-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Solberg closed DERBY-3415. -- 'DataSourceSerializationTestjunit.framework.AssertionFailedError' on 'extin\ClientConnectionPoolDataSource-10_1_3_1.ser' on Windows. Key: DERBY-3415 URL: https://issues.apache.org/jira/browse/DERBY-3415 Project: Derby Issue Type: Bug Components: Regression Test Failure, Test Affects Versions: 10.4.0.0 Environment: OS: Microsoft(R) Windows(R) Server 2003, - 5.2.3790 Service Pack 2 WindowsNT 2 5 Microsoft© Windows VistaT Ultimate - 6.0.6000 N/A Build 6000 WindowsNT 0 6 Microsoft Windows XP Professional - 5.1.2600 Service Pack 2 Build 2600 CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57 Cygwin JVM: Sun Microsystems Inc. 1.6.0 / 10.0-b18 Sun Microsystems Inc. 1.5.0_14-b03 Sun Microsystems Inc. java version 1.5.0_05. Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05). Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing) Sun Microsystems Inc. java version 1.4.2_10. Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03). Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode) Reporter: Ole Solberg Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3415-1a.diff See e.g. http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-627523.html w2003, vista. jvm1.6: 1) DataSourceSerializationTestjunit.framework.AssertionFailedError: extin\ClientConnectionPoolDataSource-10_1_3_1.ser at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:130) at org.apache.derbyTesting.junit.DropDatabaseSetup.access$000(DropDatabaseSetup.java:35) at org.apache.derbyTesting.junit.DropDatabaseSetup$1.run(DropDatabaseSetup.java:105) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:102) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:98) at org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:127) at junit.extensions.TestSetup$1.protect(TestSetup.java:22) at junit.extensions.TestSetup.run(TestSetup.java:25) XP. jvm 1.5, jvm 1.4: 1) DataSourceSerializationTestjunit.framework.AssertionFailedError: extin\EmbeddedDataSource-10_0_2_1.ser at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:130) at org.apache.derbyTesting.junit.DropDatabaseSetup.access$000(DropDatabaseSetup.java:35) at org.apache.derbyTesting.junit.DropDatabaseSetup$1.run(DropDatabaseSetup.java:105) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:102) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:98) at org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:127) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:23) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Opinions please - some questions regarding replication
Narayanan [EMAIL PROTECTED] writes: Daniel John Debrunner wrote: Sealing does not hide packages from other code, does it? I thought it only prevented other code from inserting classes into the same package. Dan. From Derby-2071 I can see that accessing classes from org.apache.derby.iapi.services.io in another jar can cause you a sealing violation. I think that's because accessing classes from another jar will cause Derby's build system to include those classes in that other jar as well, unless it's explicitly told not to do so. See the findDependencies() method in org.apache.derbyBuild.classlister. Also I found If you try to load a class in a sealed package from another source other than the JAR file in which the sealed package lives, the JVM will throw a |SecurityException|. here http://www.ibm.com/developerworks/library/j-jar/#N101D6 as the last line in the Package sealing sub-header. By load a class ... from another source I think he means that the loaded class is located in another source, not that the code that causes the class to be loaded is in another source. -- Knut Anders
[jira] Closed: (DERBY-3224) Get Suites.All to run on the phoneME advanced platform
[ https://issues.apache.org/jira/browse/DERBY-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vemund Østgaard closed DERBY-3224. -- Resolution: Fixed Thanks Myrna, I don't have any more work left on this now. Get Suites.All to run on the phoneME advanced platform -- Key: DERBY-3224 URL: https://issues.apache.org/jira/browse/DERBY-3224 Project: Derby Issue Type: Test Components: Test Environment: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 JVM: CVM phoneme_advanced_mr2-b34 (interpreter loop) Reporter: Vemund Østgaard Assignee: Vemund Østgaard Attachments: 3224-diff, 3224-diff.stat, 3224-diffv2, 3224-diffv2.stat, 3224-diffv3, 3224-diffv3.stat I'm trying to get suites.All to run on the phoneME advanced platform. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-3382) Replication: Slave must inform master if DBs are out of sync.
[
https://issues.apache.org/jira/browse/DERBY-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569227#action_12569227
]
jorgenlo edited comment on DERBY-3382 at 2/15/08 2:40 AM:
---
I had a look at the NPE, which is caused by LogToFile calling
masterFactory#flushedTo:
LogToFile lines 3966 and on...:
if (inReplicationMasterMode) {
masterFactory.flushedTo(LogCounter.
makeLogInstantAsLong(fileNumber,
wherePosition));
}
Seems like LogToFile was never informed that it is no longer in replication
mode :-/
was (Author: jorgenlo):
I had a look at the hang, which is caused by LogToFile calling
masterFac#flushedTo:
lines 3966 and on...:
if (inReplicationMasterMode) {
masterFactory.flushedTo(LogCounter.
makeLogInstantAsLong(fileNumber,
wherePosition));
}
Seems like LogToFile was never informed that it is no longer in replication
mode :-/
Replication: Slave must inform master if DBs are out of sync.
-
Key: DERBY-3382
URL: https://issues.apache.org/jira/browse/DERBY-3382
Project: Derby
Issue Type: Bug
Components: Replication
Affects Versions: 10.4.0.0
Reporter: Øystein Grøvlen
Assignee: Jørgen Løland
Fix For: 10.4.0.0
Attachments: derby-3382-1a.diff, derby-3382-1a.stat
If I copy the database to the slave before booting the master, slave will be
out of sync with the master since new log records are created during booting.
The slave will then stop replication, but the master will not be notified.
If I then try to stop or failover the master the master will hang.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3382) Replication: Slave must inform master if DBs are out of sync.
[
https://issues.apache.org/jira/browse/DERBY-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569227#action_12569227
]
Jørgen Løland commented on DERBY-3382:
--
I had a look at the hang, which is caused by LogToFile calling
masterFac#flushedTo:
lines 3966 and on...:
if (inReplicationMasterMode) {
masterFactory.flushedTo(LogCounter.
makeLogInstantAsLong(fileNumber,
wherePosition));
}
Seems like LogToFile was never informed that it is no longer in replication
mode :-/
Replication: Slave must inform master if DBs are out of sync.
-
Key: DERBY-3382
URL: https://issues.apache.org/jira/browse/DERBY-3382
Project: Derby
Issue Type: Bug
Components: Replication
Affects Versions: 10.4.0.0
Reporter: Øystein Grøvlen
Assignee: Jørgen Løland
Fix For: 10.4.0.0
Attachments: derby-3382-1a.diff, derby-3382-1a.stat
If I copy the database to the slave before booting the master, slave will be
out of sync with the master since new log records are created during booting.
The slave will then stop replication, but the master will not be notified.
If I then try to stop or failover the master the master will hang.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2559) recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2559: --- Attachment: derby-2559-3a-documentation.diff derby-2559-2a-defenses.diff I have attached two more patches: - derby-2559-2a-defenses.diff: Does some defensive checking to ensure no exception is thrown when it should not be. - derby-2559-3a-documentation.diff: Fixes to the documentation, both formatting and content. Patches ready for review. I'm especially awaiting comments on the 2a patch. recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails Key: DERBY-2559 URL: https://issues.apache.org/jira/browse/DERBY-2559 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Myrna van Lunteren Assignee: Kristian Waagan Fix For: 10.4.0.0 Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff Consider the following code snippet from test DataSourceReferenceTest: Referenceable refDS = (Referenceable) ds; Reference dsAsReference = refDS.getReference(); String factoryClassName = dsAsReference.getFactoryClassName(); ObjectFactory factory = (ObjectFactory) Class.forName(factoryClassName).newInstance(); Object recreatedDS = factory.getObjectInstance(dsAsReference, null, null, null); - When ds is a ClientDataSource40 (i.e. when running with jdk16), recreatedDS is null. Note, that this showed up only after converting the test to junit, because the original test hardcoded the ds to be a ClientDataSource. I confirmed this not to be related to my changes for DERBY-2296 (which prompted me to convert the test), by backing out my changes to ClientBaseDataSource and client/am/Connection and rerunning the test (needed some minor adjustments of expected values table/array). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2559) recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2559: --- Derby Info: [Patch Available] recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails Key: DERBY-2559 URL: https://issues.apache.org/jira/browse/DERBY-2559 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Myrna van Lunteren Assignee: Kristian Waagan Fix For: 10.4.0.0 Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff Consider the following code snippet from test DataSourceReferenceTest: Referenceable refDS = (Referenceable) ds; Reference dsAsReference = refDS.getReference(); String factoryClassName = dsAsReference.getFactoryClassName(); ObjectFactory factory = (ObjectFactory) Class.forName(factoryClassName).newInstance(); Object recreatedDS = factory.getObjectInstance(dsAsReference, null, null, null); - When ds is a ClientDataSource40 (i.e. when running with jdk16), recreatedDS is null. Note, that this showed up only after converting the test to junit, because the original test hardcoded the ds to be a ClientDataSource. I confirmed this not to be related to my changes for DERBY-2296 (which prompted me to convert the test), by backing out my changes to ClientBaseDataSource and client/am/Connection and rerunning the test (needed some minor adjustments of expected values table/array). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Broken target 'ant javadoc'
Kristian Waagan wrote: Hello, My commit for DERBY-1318 broke the target 'javadoc', more specifically 'testing-javadoc'. The reason seems to be that the directory 'serialized-data-sources' is not a valid Java package name. My question is, which solution should I choose to fix the problem: a) Renamed the directory (i.e. 'serializedDataSources') b) Change the target to not generate JavaDoc for the testData directory (can be done by adding it to an exclude list). c) Should the test data be moved outside the source tree? Any opinions? If I don't get any feedback, I think I'll go for option a just because it's simple. Renamed the directory and updated the references to it with revision 628038. -- Kristian thanks,
[jira] Updated: (DERBY-3406) IllegalMonitorStateException in ...replication.master.AsynchronousLogShipper.workToDo(:320)
[
https://issues.apache.org/jira/browse/DERBY-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
V.Narayanan updated DERBY-3406:
---
Attachment: Derby3406.stat
Derby3406.diff
The attached patch fixes the issue pointed out. I ran the repro attached and
found that it passed.
Pls find the execution of the repro below.
ij call SYSCS_UTIL.SYSCS_FREEZE_DATABASE();
Statement executed.
ij connect
'jdbc:derby://localhost:1527/replicationdb;startMaster=true;slaveHost=localhost;slavePort=8001';
ij(CONNECTION1) create table tchar( i int, c char(1) for bit data default
x'02');
0 rows inserted/updated/deleted
ij(CONNECTION1) create table tchar1 (i int, c char(5) for bit data default
x'2020202020', v varchar(5) for bit data default x'2020', l long varchar for
bit data default x'303030');
0 rows inserted/updated/deleted
ij(CONNECTION1) drop table tchar;
0 rows inserted/updated/deleted
ij(CONNECTION1) drop table tchar1;
0 rows inserted/updated/deleted
ij(CONNECTION1) create table i1 (i int, t int, s smallint, l bigint, r real,
dp double, dc dec);
0 rows inserted/updated/deleted
ij(CONNECTION1)
IllegalMonitorStateException in
...replication.master.AsynchronousLogShipper.workToDo(:320)
---
Key: DERBY-3406
URL: https://issues.apache.org/jira/browse/DERBY-3406
Project: Derby
Issue Type: Bug
Components: Replication
Affects Versions: 10.4.0.0
Environment: Trunk: svn r620716
Reporter: Ole Solberg
Assignee: V.Narayanan
Attachments: derby.log, derby.log, Derby3406.diff, Derby3406.stat
Example test output:
ij -- Derby-34
create table tchar( i int, c char(1) for bit data default x'02');
0 rows inserted/updated/deleted
ij create table tchar1 (i int, c char(5) for bit data default
x'2020202020',
v varchar(5) for bit data default x'2020',
l long varchar for bit data default x'303030');
ERROR XJ001: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC:
java.lang.IllegalMonitorStateExceptionXJ001.U
ij drop table tchar;
ERROR 08006: A network protocol error was encountered and the connection
has been terminated: the requested command encountered an unarchitected and
implementation-specific condition for which there was no architected message
ij drop table tchar1;
ERROR 08003: No current connection.
ij -- insert various numeric types into other numeric types
create table i1 (i int, t int, s smallint, l bigint, r real, dp double, dc
dec);
ERROR 08003: No current connection.
Master derby log contains:
.
.
Connection number: 4.
Replication master role started for database
'/home/os136789/Replication/testing/db_master/test'.
2008-02-12 07:37:05.050 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
/home/os136789/Replication/testing/db_master/test), (DRDAID = {4}), Apache
Derby Network Server connected to database
/home/os136789/Replication/testing/db_master/test;slavePort=;startMaster=true;slaveHost=urd12
Connection number: 5.
2008-02-12 07:37:15.924 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
/home/os136789/Replication/testing/db_master/test), (DRDAID = {5}), Apache
Derby Network Server connected to database
/home/os136789/Replication/testing/db_master/test
2008-02-12 07:37:17.815 GMT Thread[DRDAConnThread_2,5,main] (XID = 144),
(SESSIONID = 3), (DATABASE =
/home/os136789/Replication/testing/db_master/test), (DRDAID =
O19F7421.DA48-794884131429056622{5}), Cleanup action starting
2008-02-12 07:37:17.815 GMT Thread[DRDAConnThread_2,5,main] (XID = 144),
(SESSIONID = 3), (DATABASE =
/home/os136789/Replication/testing/db_master/test), (DRDAID =
O19F7421.DA48-794884131429056622{5}), Failed Statement is: null
java.lang.IllegalMonitorStateException
at java.lang.Object.notify(Native Method)
at
org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.workToDo(AsynchronousLogShipper.java:320)
at
org.apache.derby.impl.services.replication.master.MasterController.workToDo(MasterController.java:434)
at
org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.switchDirtyBuffer(ReplicationLogBuffer.java:321)
at
org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.appendLog(ReplicationLogBuffer.java:148)
at
org.apache.derby.impl.services.replication.master.MasterController.appendLog(MasterController.java:320)
at
org.apache.derby.impl.store.raw.log.LogAccessFile.writeToLog(LogAccessFile.java:787)
at
org.apache.derby.impl.store.raw.log.LogAccessFile.flushDirtyBuffers(LogAccessFile.java:534)
at
org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:4007)
at
[jira] Commented: (DERBY-3379) No Current connection on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing
[ https://issues.apache.org/jira/browse/DERBY-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569260#action_12569260 ] Knut Anders Hatlen commented on DERBY-3379: --- I think the approach is OK, although it sounds better if the chaining bits were set correctly in the first place. It's not quite clear to me where/how the chaining bits are set the first time, but if I understand correctly, Statement.flowCloseOutsideUOW() will only be called if nothing needs to be sent to the server on Statement.close(). Could we somehow use this to send a flag down the call tree so that the chaining bits are set correctly? Should previousUsedDssMark have been reset in clearBuffer()? Should endDssChain() also check that (dssLengthLocation_ == offset_) so that we're completely sure the last DSS is empty/missing? No Current connection on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing - Key: DERBY-3379 URL: https://issues.apache.org/jira/browse/DERBY-3379 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 Reporter: Kathey Marsden Assignee: Kristian Waagan Attachments: derby-3379-1a-enforce_no_chaining.diff, derby-3379-1a-enforce_no_chaining.diff, derby-3379-1a-enforce_no_chaining.stat, derby-3379-1a-enforce_no_chaining.stat, derby-3379-1b-enforce_no_chaining.diff, derby-3379-1c-enforce_no_chaining.diff, derby-3379-1c-enforce_no_chaining.stat This is the client version of bug DERBY-2142. It can be reproduced by enabling the test, DataSourceTest.testPooledReuseOnClose() for client. I am opening a new issue for client as the embedded fix was backported to 10.1 and I am guessing the client fix won't be backported that far. Better to keep it as a separate issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3354) Select from large lob table with embedded gives OutOfMemoryError
[ https://issues.apache.org/jira/browse/DERBY-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569268#action_12569268 ] Øystein Grøvlen commented on DERBY-3354: Kathey, I agreed that more needs to be done for a final patch. I just put together a patch with the core fix to make it possible to try out the fix. To your issues: 1) Creating a finally block in EmbedBlob seems like a good idea. I also agree that we can remove similar code from the stored procedures. 2) I will think about solution for jdk15. The problem introduced by 10.3 is that the lob mapping keeps Blob/Clob objects alive that earlier would be gc'ed when it was no longer referred by the user. I guess another level of indirection would make it possible to use finalizers to clean up, but I am not sure that is a good idea. A work-around is to not create Blob objects in the first place, but use ResultSet#getBytes etc instead. So the problem is limited to the case where a Blob object need to be accessible after a call to ResultSet#next, but not until commit. 3) Seems like there is come concurrent access to the HashMap. I would guess that this is because the iterator created by rollback, detects that the underlying collection has been changed. Probably through the calls to free in the loop using the iterator. I think this show that something needs to be reorganized a bit here. Select from large lob table with embedded gives OutOfMemoryError Key: DERBY-3354 URL: https://issues.apache.org/jira/browse/DERBY-3354 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Kathey Marsden Attachments: derby-3354.diff, LocLeak.java Retrieving from a large table with lobs gives an OutOfMemoryException, even if free() is explictly called on the lob. I believe this is because EmbedConnection.addLobMapping is called for every lob creation but is never cleared until commit or rollback, even if the lob is freed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2559) recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569269#action_12569269 ] Knut Anders Hatlen commented on DERBY-2559: --- 2a looks good. Seems like the patch makes the implementation more in line with the description in the javadoc, so that's good. recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails Key: DERBY-2559 URL: https://issues.apache.org/jira/browse/DERBY-2559 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Myrna van Lunteren Assignee: Kristian Waagan Fix For: 10.4.0.0 Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff Consider the following code snippet from test DataSourceReferenceTest: Referenceable refDS = (Referenceable) ds; Reference dsAsReference = refDS.getReference(); String factoryClassName = dsAsReference.getFactoryClassName(); ObjectFactory factory = (ObjectFactory) Class.forName(factoryClassName).newInstance(); Object recreatedDS = factory.getObjectInstance(dsAsReference, null, null, null); - When ds is a ClientDataSource40 (i.e. when running with jdk16), recreatedDS is null. Note, that this showed up only after converting the test to junit, because the original test hardcoded the ds to be a ClientDataSource. I confirmed this not to be related to my changes for DERBY-2296 (which prompted me to convert the test), by backing out my changes to ClientBaseDataSource and client/am/Connection and rerunning the test (needed some minor adjustments of expected values table/array). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3421) Remove unused code for caching of connect bytes
Remove unused code for caching of connect bytes --- Key: DERBY-3421 URL: https://issues.apache.org/jira/browse/DERBY-3421 Project: Derby Issue Type: Improvement Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor The client driver has code for caching connect bytes, but it is not used. This unused code clutters the rest of the code and makes it harder to understand. Secondly, the variable used to determine if the cached connect bytes can be used is public in am.Connection. If someone has historic information about this feature, it would be nice if they could add the information to this Jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3422) Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets()
Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets() Key: DERBY-3422 URL: https://issues.apache.org/jira/browse/DERBY-3422 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor DatabaseMetaData.autoCommitFailureClosesAllResultSets() returns false both on the client and on embedded. However, the embedded driver does in fact close all open result sets when an error occurs in auto-commit mode. There is a test case in jdbc4.TestDbMetaData to test this (testAutoCommitFailure), but it only uses ResultSet.isClosed() to check whether or not the result set is closed after the failure. Because of DERBY-3404, isClosed() returns false for the result sets that have been closed because of the failure, so the test doesn't reveal the bug. If the test is changed to invoke methods on the result set (e.g. next()) instead of calling isClosed(), we'll see that the result set is in fact closed and get an SQLException with SQL state XCL16. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569278#action_12569278 ] Knut Anders Hatlen commented on DERBY-3404: --- The failure in jdbc4.TestDbMetaData is actually a bug in EmbedDatabaseMetaData40, see DERBY-3422. This bug has been hidden because ResultSet.isClosed() previously returned false for a ResultSet that in fact had been closed. When isClosed() correctly returned false, the test revealed that there was a mismatch between the actual behaviour and what the meta-data said the behaviour should be. EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java, d3404-v1.diff, d3404-v1.stat The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3382) Replication: Slave must inform master if DBs are out of sync.
[ https://issues.apache.org/jira/browse/DERBY-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569277#action_12569277 ] Øystein Grøvlen commented on DERBY-3382: Jørgen Løland (JIRA) wrote: Seems like LogToFile was never informed that it is no longer in replication mode :-/ Strictly speaking, it has never been in replication mode since replication startup did not succeed. Replication: Slave must inform master if DBs are out of sync. - Key: DERBY-3382 URL: https://issues.apache.org/jira/browse/DERBY-3382 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0 Reporter: Øystein Grøvlen Assignee: Jørgen Løland Fix For: 10.4.0.0 Attachments: derby-3382-1a.diff, derby-3382-1a.stat If I copy the database to the slave before booting the master, slave will be out of sync with the master since new log records are created during booting. The slave will then stop replication, but the master will not be notified. If I then try to stop or failover the master the master will hang. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3163) Derby JUnit test framework adaptions to run existing tests against replicated databases
[ https://issues.apache.org/jira/browse/DERBY-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Øystein Grøvlen updated DERBY-3163: --- Derby Info: (was: [Patch Available]) Thanks, Ole. Committed v4 of patches as revision 628073. Derby JUnit test framework adaptions to run existing tests against replicated databases --- Key: DERBY-3163 URL: https://issues.apache.org/jira/browse/DERBY-3163 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Ole Solberg Assignee: Ole Solberg Priority: Minor Attachments: derby-3163.1-v1.diff.txt, derby-3163.1-v2.diff.txt, derby-3163.1-v3.diff.txt, derby-3163.1-v4.diff.txt, derby-3163.2-v1.diff.txt, derby-3163.2-v2.diff.txt, derby-3163.2-v3.diff.txt, derby-3163.2-v4.diff.txt Extensions to run existing Apache Derby tests (old test harness tests (derbyall kind) and junit tests) This requires - Running existing tests against already started servers on non-localhost machines. - verificationclients checking slave vs. master. - ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3422) Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets()
[ https://issues.apache.org/jira/browse/DERBY-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3422: -- Attachment: test.diff Attaching a patch which updates the test so that it exposes the bug. Instead of calling isClosed(), it calls ResultSet.next() and checks whether an exception with SQL state XCL16 is thrown. With this change, the test fails on embedded and passes on the client. Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets() Key: DERBY-3422 URL: https://issues.apache.org/jira/browse/DERBY-3422 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: test.diff DatabaseMetaData.autoCommitFailureClosesAllResultSets() returns false both on the client and on embedded. However, the embedded driver does in fact close all open result sets when an error occurs in auto-commit mode. There is a test case in jdbc4.TestDbMetaData to test this (testAutoCommitFailure), but it only uses ResultSet.isClosed() to check whether or not the result set is closed after the failure. Because of DERBY-3404, isClosed() returns false for the result sets that have been closed because of the failure, so the test doesn't reveal the bug. If the test is changed to invoke methods on the result set (e.g. next()) instead of calling isClosed(), we'll see that the result set is in fact closed and get an SQLException with SQL state XCL16. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3421) Remove unused code for caching of connect bytes
[ https://issues.apache.org/jira/browse/DERBY-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3421: --- Derby Info: [Patch Available] Remove unused code for caching of connect bytes --- Key: DERBY-3421 URL: https://issues.apache.org/jira/browse/DERBY-3421 Project: Derby Issue Type: Improvement Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Attachments: derby-3421-1a-removal.diff, derby-3421-1a-removal.stat The client driver has code for caching connect bytes, but it is not used. This unused code clutters the rest of the code and makes it harder to understand. Secondly, the variable used to determine if the cached connect bytes can be used is public in am.Connection. If someone has historic information about this feature, it would be nice if they could add the information to this Jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1387) Add JMX extensions to Derby
[ https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569296#action_12569296 ] John H. Embretsen commented on DERBY-1387: -- I created a new wiki page to keep track of MBeans and other related information that is scattered on the wiki and elsewhere: http://wiki.apache.org/db-derby/DerbyJMX Add JMX extensions to Derby --- Key: DERBY-1387 URL: https://issues.apache.org/jira/browse/DERBY-1387 Project: Derby Issue Type: New Feature Components: Services Reporter: Sanket Sharma Assignee: John H. Embretsen Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff, DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff, DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip, DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat, derby1387_simple_9_1.txt, derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, jmxFuncspec.html, jmxFuncspec.html, Requirements for JMX Updated.html, Requirements for JMX.html, Requirements for JMX.zip This is a draft requirement specification for adding monitoring and management extensions to Apache Derby using JMX. The requirements document has been uploaded on JIRA as well as the Derby Wiki page at http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX Developers and Users are requested to please look at the document (feature list in particular) and add their own rating to features by adding a coloumn to the table. Comments are welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Opinions please - some questions regarding replication
Daniel John Debrunner wrote: Knut Anders Hatlen wrote: Narayanan [EMAIL PROTECTED] writes: If you try to load a class in a sealed package from another source other than the JAR file in which the sealed package lives, the JVM will throw a |SecurityException|. here http://www.ibm.com/developerworks/library/j-jar/#N101D6 as the last line in the Package sealing sub-header. By load a class ... from another source I think he means that the loaded class is located in another source, not that the code that causes the class to be loaded is in another source. Right, derbynet.jar uses sealed classes from derby.jar, so sealing is not an issue here. Dan. Well I guess I misinterpreted this. But just thinking aloud why isn't derby.jar sealed in entirety if sealed classes can anyway be used from outside? Well maybe because the presence of the class was required in other jars as well and we wanted to allow the derby build system to include these classes in the other jars without causing a sealing violation similar to Derby-2701 (keeping with the explanation given by knut). Well I must admit I am not entirely clear about the sealing in the jar building system of derby. I will dig in more here. Narayanan
Re: Opinions please - some questions regarding replication
Knut Anders Hatlen wrote: Narayanan [EMAIL PROTECTED] writes: If you try to load a class in a sealed package from another source other than the JAR file in which the sealed package lives, the JVM will throw a |SecurityException|. here http://www.ibm.com/developerworks/library/j-jar/#N101D6 as the last line in the Package sealing sub-header. By load a class ... from another source I think he means that the loaded class is located in another source, not that the code that causes the class to be loaded is in another source. Right, derbynet.jar uses sealed classes from derby.jar, so sealing is not an issue here. Dan.
[jira] Closed: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)
[ https://issues.apache.org/jira/browse/DERBY-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan closed DERBY-3359. -- The log shipper needs to be modified to vary the shipping intervals dynamically (based on load) --- Key: DERBY-3359 URL: https://issues.apache.org/jira/browse/DERBY-3359 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Fix For: 10.4.0.0 Attachments: DynamicLogShipping_v1.diff, DynamicLogShipping_v1.stat, DynamicLogShipping_v2.diff, DynamicLogShipping_v2.stat, DynamicLogShipping_v3.diff, DynamicLogShipping_v3.stat, DynamicLogShipping_v4.diff, DynamicLogShipping_v4.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Opinions please - some questions regarding replication
Narayanan wrote: Daniel John Debrunner wrote: Knut Anders Hatlen wrote: Narayanan [EMAIL PROTECTED] writes: If you try to load a class in a sealed package from another source other than the JAR file in which the sealed package lives, the JVM will throw a |SecurityException|. here http://www.ibm.com/developerworks/library/j-jar/#N101D6 as the last line in the Package sealing sub-header. By load a class ... from another source I think he means that the loaded class is located in another source, not that the code that causes the class to be loaded is in another source. Right, derbynet.jar uses sealed classes from derby.jar, so sealing is not an issue here. Dan. Well I guess I misinterpreted this. But just thinking aloud why isn't derby.jar sealed in entirety if sealed classes can anyway be used from outside? Well maybe because the presence of the class was required in other jars as well and we wanted to allow the derby build system to include these classes in the other jars without causing a sealing violation similar to Derby-2701 (keeping with the explanation given by knut). Right, in some cases we need the same class in multiple jars (e.g. sysinfo related classes), in other cases we put classes from different jars in the same package (o.a.d.jdbc has embedded drivers from derby.jar and client drivers from derbyclient.jar). Dan.
Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
John H. Embretsen (JIRA) wrote: I created a new wiki page to keep track of MBeans and other related information that is scattered on the wiki and elsewhere: http://wiki.apache.org/db-derby/DerbyJMX Thanks John, another great page. Dan.
[jira] Updated: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)
[ https://issues.apache.org/jira/browse/DERBY-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3359: --- Component/s: Replication Affects Version/s: 10.4.0.0 Fix Version/s: 10.4.0.0 The log shipper needs to be modified to vary the shipping intervals dynamically (based on load) --- Key: DERBY-3359 URL: https://issues.apache.org/jira/browse/DERBY-3359 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Fix For: 10.4.0.0 Attachments: DynamicLogShipping_v1.diff, DynamicLogShipping_v1.stat, DynamicLogShipping_v2.diff, DynamicLogShipping_v2.stat, DynamicLogShipping_v3.diff, DynamicLogShipping_v3.stat, DynamicLogShipping_v4.diff, DynamicLogShipping_v4.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)
[ https://issues.apache.org/jira/browse/DERBY-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan resolved DERBY-3359. Resolution: Fixed All relevant patches have been committed. Resolving issue! The log shipper needs to be modified to vary the shipping intervals dynamically (based on load) --- Key: DERBY-3359 URL: https://issues.apache.org/jira/browse/DERBY-3359 Project: Derby Issue Type: Sub-task Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Fix For: 10.4.0.0 Attachments: DynamicLogShipping_v1.diff, DynamicLogShipping_v1.stat, DynamicLogShipping_v2.diff, DynamicLogShipping_v2.stat, DynamicLogShipping_v3.diff, DynamicLogShipping_v3.stat, DynamicLogShipping_v4.diff, DynamicLogShipping_v4.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription
Filter: Derby: JIRA issues with patch available (15 issues)
Subscriber: derby-dev
Key Summary
DERBY-3421 Remove unused code for caching of connect bytes
https://issues.apache.org/jira/browse/DERBY-3421
DERBY-3382 Replication: Slave must inform master if DBs are out of sync.
https://issues.apache.org/jira/browse/DERBY-3382
DERBY-2559 recreating a datasource using javax.naming.Reference from a
ClientDataSource40 fails
https://issues.apache.org/jira/browse/DERBY-2559
DERBY-3379 No Current connection on PooledConnection.getConnection() if
pooled connection is reused during connectionClosed processing
https://issues.apache.org/jira/browse/DERBY-3379
DERBY-3299 Uniqueness violation error (23505) occurs after dropping a PK
constraint if there exists a foreign key on the same columns.
https://issues.apache.org/jira/browse/DERBY-3299
DERBY-3014 Make
SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.username') return NULL
instead of the hash value of the password
https://issues.apache.org/jira/browse/DERBY-3014
DERBY-1824 Permission/privlege names in exceptions should be in upper case as
keywords, not lower case.
https://issues.apache.org/jira/browse/DERBY-1824
DERBY-3326 Introduce a caching logical connection and logical prepared
statement in the client driver
https://issues.apache.org/jira/browse/DERBY-3326
DERBY-3001 SYSTABLES documentation for TABLETYPE should include 'A' (Synonym)
https://issues.apache.org/jira/browse/DERBY-3001
DERBY-3409 Remove JDBC 2.0-specific topics from Reference Manual and merge
implementation notes as needed
https://issues.apache.org/jira/browse/DERBY-3409
DERBY-3205 Replication: Add connection url command options for starting,
stopping slave and for failover
https://issues.apache.org/jira/browse/DERBY-3205
DERBY-2871 XATransactionTest gets XaException: Error executing a
XAResource.commit(), server returned XAER_PROTO.
https://issues.apache.org/jira/browse/DERBY-2871
DERBY-2954 Add commands to NetworkServerControl for interacting with the
replication functionality
https://issues.apache.org/jira/browse/DERBY-2954
DERBY-2953 Dump the information about rollbacks of the global transaction
(introduced in DERBY-2220 and DERBY-2432) to derby.log
https://issues.apache.org/jira/browse/DERBY-2953
DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227
[jira] Updated: (DERBY-3406) IllegalMonitorStateException in ...replication.master.AsynchronousLogShipper.workToDo(:320)
[
https://issues.apache.org/jira/browse/DERBY-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
V.Narayanan updated DERBY-3406:
---
Fix Version/s: 10.4.0.0
IllegalMonitorStateException in
...replication.master.AsynchronousLogShipper.workToDo(:320)
---
Key: DERBY-3406
URL: https://issues.apache.org/jira/browse/DERBY-3406
Project: Derby
Issue Type: Bug
Components: Replication
Affects Versions: 10.4.0.0
Environment: Trunk: svn r620716
Reporter: Ole Solberg
Assignee: V.Narayanan
Fix For: 10.4.0.0
Attachments: derby.log, derby.log, Derby3406.diff, Derby3406.stat
Example test output:
ij -- Derby-34
create table tchar( i int, c char(1) for bit data default x'02');
0 rows inserted/updated/deleted
ij create table tchar1 (i int, c char(5) for bit data default
x'2020202020',
v varchar(5) for bit data default x'2020',
l long varchar for bit data default x'303030');
ERROR XJ001: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC:
java.lang.IllegalMonitorStateExceptionXJ001.U
ij drop table tchar;
ERROR 08006: A network protocol error was encountered and the connection
has been terminated: the requested command encountered an unarchitected and
implementation-specific condition for which there was no architected message
ij drop table tchar1;
ERROR 08003: No current connection.
ij -- insert various numeric types into other numeric types
create table i1 (i int, t int, s smallint, l bigint, r real, dp double, dc
dec);
ERROR 08003: No current connection.
Master derby log contains:
.
.
Connection number: 4.
Replication master role started for database
'/home/os136789/Replication/testing/db_master/test'.
2008-02-12 07:37:05.050 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
/home/os136789/Replication/testing/db_master/test), (DRDAID = {4}), Apache
Derby Network Server connected to database
/home/os136789/Replication/testing/db_master/test;slavePort=;startMaster=true;slaveHost=urd12
Connection number: 5.
2008-02-12 07:37:15.924 GMT Thread[DRDAConnThread_2,5,main] (DATABASE =
/home/os136789/Replication/testing/db_master/test), (DRDAID = {5}), Apache
Derby Network Server connected to database
/home/os136789/Replication/testing/db_master/test
2008-02-12 07:37:17.815 GMT Thread[DRDAConnThread_2,5,main] (XID = 144),
(SESSIONID = 3), (DATABASE =
/home/os136789/Replication/testing/db_master/test), (DRDAID =
O19F7421.DA48-794884131429056622{5}), Cleanup action starting
2008-02-12 07:37:17.815 GMT Thread[DRDAConnThread_2,5,main] (XID = 144),
(SESSIONID = 3), (DATABASE =
/home/os136789/Replication/testing/db_master/test), (DRDAID =
O19F7421.DA48-794884131429056622{5}), Failed Statement is: null
java.lang.IllegalMonitorStateException
at java.lang.Object.notify(Native Method)
at
org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.workToDo(AsynchronousLogShipper.java:320)
at
org.apache.derby.impl.services.replication.master.MasterController.workToDo(MasterController.java:434)
at
org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.switchDirtyBuffer(ReplicationLogBuffer.java:321)
at
org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.appendLog(ReplicationLogBuffer.java:148)
at
org.apache.derby.impl.services.replication.master.MasterController.appendLog(MasterController.java:320)
at
org.apache.derby.impl.store.raw.log.LogAccessFile.writeToLog(LogAccessFile.java:787)
at
org.apache.derby.impl.store.raw.log.LogAccessFile.flushDirtyBuffers(LogAccessFile.java:534)
at
org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:4007)
at
org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:1769)
at
org.apache.derby.impl.store.raw.log.FileLogger.flush(FileLogger.java:585)
at
org.apache.derby.impl.store.raw.xact.Xact.prepareCommit(Xact.java:764)
at org.apache.derby.impl.store.raw.xact.Xact.commit(Xact.java:852)
at org.apache.derby.impl.store.raw.xact.Xact.commit(Xact.java:649)
at
org.apache.derby.impl.store.access.RAMTransaction.commit(RAMTransaction.java:1964)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(GenericLanguageConnectionContext.java:1183)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(GenericLanguageConnectionContext.java:1003)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(TransactionResourceImpl.java:237)
at
org.apache.derby.impl.jdbc.EmbedConnection.commit(EmbedConnection.java:1482)
at
[jira] Updated: (DERBY-3329) Enable statement pooling in the client JDBC driver
[ https://issues.apache.org/jira/browse/DERBY-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3329: --- Attachment: derby-3329-1a-enable_statement_pooling.diff 'derby-3329-1a-enable_statement_pooling.diff' modifies ClientPooledConnection.java and enables statement pooling under the following preconditions: * Patches for DERBY-3326 and DERBY-3328 must be applied. * Connections must be obtained through a ClientConnectionPoolDataSource * The property maxStatements must be set to something larger than zero in CCPDS. Note that statement pooling is not enabled for XA connections yet. That would require a trivial change in ClientPooledConnection and addition of the maxStatements property in the XA data source. Note that there are no proper testing yet, but I have run through jdbc4.ConnectionTest and jdbc4.PreparedStatementTest without errors (with statement pooling enabled). Tests will follow in a separate patch. Patch ready for review. Enable statement pooling in the client JDBC driver -- Key: DERBY-3329 URL: https://issues.apache.org/jira/browse/DERBY-3329 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Trivial Fix For: 10.4.0.0 Attachments: derby-3329-1a-enable_statement_pooling.diff Enable statement pooling in the client JDBC driver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3192) Cache session data in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569314#action_12569314 ] Dyre Tjeldvoll commented on DERBY-3192: --- I have updated the writeup at http://wiki.apache.org/db-derby/Derby3192Writeup so that it correctly describes the mark2.v3 patch. Cache session data in the client driver --- Key: DERBY-3192 URL: https://issues.apache.org/jira/browse/DERBY-3192 Project: Derby Issue Type: Improvement Components: JDBC, Network Client, Network Server, Performance, SQL Affects Versions: 10.3.1.4 Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Attachments: derby-3192-mark2.v1.diff, derby-3192-mark2.v2.diff, derby-3192-mark2.v3.diff, derby-3192-test.fup1.diff, derby-3192-test.fup2.diff, derby-3192-test.v1.diff, derby-3192-test.v1.stat, derby-3192.prelim1.diff The reason for doing this is to avoid a rather substantial performance hit observed when the client driver is used together with an appserver that uses connection pooling. There are two problems: 1) The connection pool will compare the isolation level it has stored for the connection with the value returned from Connection.getTransactionIsolation() each and every time someone requests a new connection from the pool. 2) The users of the connection pool (ab)use it to avoid having to keep track of their current connection. So each time a query needs to be executed a call to the connection pool's getConnection() method is made. Getting a connection from the connection pool like this also means that a new PreparedStatement must be prepared each time. The net result is that each query results in the following sequence: getConnection() getTransactionIsolation() -- roundtrip + lookup in server's statement cache prepareStatment() -- roundtrip + lookup in server's statement cache executeQuery()-- roundtrip Arguably this is a user error but when suggesting this I'm kindly informed that this works just fine with other datbases (such as PostgreSQL and ORACLE). The reason why it works is that these databases do statement caching in the driver. I've tried to implement a very (too) simple statement cache in Derby's client driver and to re-enable caching of the isolation level (see https://issues.apache.org/jira/browse/DERBY-1148). With these changes I observe a marked performance improvement when running with appserver load. A proper statment cache cannot be implemented without knowing what the current schema is. If the current schema has changed since the statement was prepared, it is no longer valid and must be evicted from the cache. The problem with caching both the isolation level and the current schema in the driver is that both can change on the server without the client detecting it (through SQL and XA and possibly stored procedures). I think this problem can be overcome if we piggy-back the information we would like to cache on messages going back to the client. This can be done by utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume 3, page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD in the reply, I think it would be possible to cache additional session information when this becomes relevant. It would also be possible to use EXCSQLSET to batch session state changes going from the client to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3400) testgetTypeInfo Fails with ibm16 while running the UpgradeTests
[ https://issues.apache.org/jira/browse/DERBY-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3400. --- Resolution: Invalid Resolving as invalid because this is a jvm issue. testgetTypeInfo Fails with ibm16 while running the UpgradeTests --- Key: DERBY-3400 URL: https://issues.apache.org/jira/browse/DERBY-3400 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr1-20080108_02) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080102 _15870 (JIT enabled) J9VM - 20080102_015870_lHdSMr JIT - r9_20080101_1821 GC - 20071224_AA) JCL - 20071219_01 sysinfo - [C:/derbydev/trunk/test] java org.apache.derby.tools.sysinfo -- Java Information -- Java Version:1.6.0 Java Vendor: IBM Corporation Java home: c:\p4client\mkutty_main\ibm16\jre Java classpath: c:/derbydev/trunk/classes;c:/derbydev/trunk/tools/java/junit.ja r;. OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 2 Java user name: mkutty Java user home: C:\Documents and Settings\Administrator Java user dir: C:\derbydev\trunk\test java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [C:\derbydev\trunk\classes] 10.4.0.0 alpha - (1) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.4.0.0 alpha - (1) Found support for locale: [de_DE] version: 10.4.0.0 alpha - (1) Found support for locale: [es] version: 10.4.0.0 alpha - (1) Found support for locale: [fr] version: 10.4.0.0 alpha - (1) Found support for locale: [hu] version: 10.4.0.0 alpha - (1) Found support for locale: [it] version: 10.4.0.0 alpha - (1) Found support for locale: [ja_JP] version: 10.4.0.0 alpha - (1) Found support for locale: [ko_KR] version: 10.4.0.0 alpha - (1) Found support for locale: [pl] version: 10.4.0.0 alpha - (1) Found support for locale: [pt_BR] version: 10.4.0.0 alpha - (1) Found support for locale: [ru] version: 10.4.0.0 alpha - (1) Found support for locale: [zh_CN] version: 10.4.0.0 alpha - (1) Found support for locale: [zh_TW] version: 10.4.0.0 alpha - (1) -- Reporter: Manjula Kutty Assignee: Kathey Marsden Fix For: 10.4.0.0 Attachments: derby-3400_diff.txt, TestDerby3400.java I can reproduce the test with the just one old version(10.2.2.0) Here is the junit stack trace 1) testGetTypeInfo(org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest)junit.framework.AssertionFailedError: Column nullability do not match for column 16 expected:1 but was:0 at org.apache.derbyTesting.junit.JDBC.assertNullability(JDBC.java:741) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.assertMetaDataResultSet(DatabaseMetaDataTest.java:2348) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetTypeInfo(DatabaseMetaDataTest.java:2230) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) More info can be found at
[jira] Updated: (DERBY-3299) Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns.
[ https://issues.apache.org/jira/browse/DERBY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A B updated DERBY-3299: --- Attachment: d3299_caUtilMethods_v2.patch Attaching d3299_caUtilMethods_v2.patch, which fixes the javadoc error mentioned by Kristian and also has some whitespace changes (to make use of tabs/spaces consistent). I committed this patch with svn # 628181: URL: http://svn.apache.org/viewvc?rev=628181view=rev This commit necessitates some cleanup/merging with the d3299_dropSharedConglom_v1.patch, so I will make the needed changes and post a dropSharedConglom_v2 patch shortly. Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns. --- Key: DERBY-3299 URL: https://issues.apache.org/jira/browse/DERBY-3299 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: A B Assignee: A B Priority: Minor Attachments: case_2.sql, d3299_caUtilMethods_v1.patch, d3299_caUtilMethods_v2.patch, d3299_createIxAction_v1.patch, d3299_dropSharedConglom_v1.patch, d3299_tests_v1.patch, d3299_v1.patch When there are multiple constraints on a single table and the constraints have the same set of columns (in the same order), Derby tries to optimize things by re-using a single backing index for all of the relevant constraints. See the executeConstantAction() method of CreateIndexConstantAction.java (search for duplicate). But there is a bug in Derby where, if one of the constraints is unique and is dropped, the uniqueness attribute of the backing index is not updated accordingly. This means that uniqueness may be incorrectly enforced where it is not required. Take the following example (Case 2 from DERBY-2204): ALTER TABLE NEWORDERS ADD CONSTRAINT NEWORDERS_PK PRIMARY KEY(NO_W_ID, NO_D_ID, NO_O_ID); ALTER TABLE NEWORDERS ADD CONSTRAINT NO_O_FK FOREIGN KEY (NO_W_ID, NO_D_ID, NO_O_ID) REFERENCES ORDERS; For these statements Derby will use a single backing index for both the primary constraint NEWORDERS_PK and the foreign key constraint NO_O_FK. That backing index will be unique because the primary key must itself be unique. If later we drop the primary key: ALTER TABLE NEWORDERS DROP CONSTRAINT NEWORDERS_PK; then the backing index needs to be converted from a unique index to a non-unique index (because a foreign key is not inherently unique). But in Derby the uniqueness attribute remains unchanged, so attempts to insert a duplicate (NO_W_ID, NO_D_ID, NO_O_ID) row into NEWORDERS will fail with error 23505, when it should really succeed. I tried this out on 10.1.3.1 and the same behavior occurs there, so marking Affects versions for everything back to that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3328) Extend client JDBC object factory with methods to create objects required for statement pooling
[ https://issues.apache.org/jira/browse/DERBY-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3328: --- Derby Info: [Patch Available] Extend client JDBC object factory with methods to create objects required for statement pooling --- Key: DERBY-3328 URL: https://issues.apache.org/jira/browse/DERBY-3328 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3328-1a-extend_jdbc_objectfactories.diff, derby-3328-1a-extend_jdbc_objectfactories.stat Since statement pooling introduces new types of objects, the factories must be extended to handle these new types. This step is primarily required because we support multiple versions of the JDBC standard, which in turn implies running with different interfaces and JVM versions with differing features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3303) ArrayIndexOutOfBoundsException at MergeSort.compare
[
https://issues.apache.org/jira/browse/DERBY-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569369#action_12569369
]
Bryan Pendleton commented on DERBY-3303:
Hi Army, thanks for working on this problem. I'll try to have a look at your
patch over the weekend (little busy today).
ArrayIndexOutOfBoundsException at MergeSort.compare
---
Key: DERBY-3303
URL: https://issues.apache.org/jira/browse/DERBY-3303
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Environment: -- Java Information --
Java Version:1.6.0_03
Java Vendor: Sun Microsystems Inc.
Java home: D:\Programs\Java\jre1.6.0_03
Java classpath: derbytools.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: Donatas
Java user home: C:\Documents and Settings\Donatas
Java user dir: d:\java\derby-10.3.2.1\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[D:\java\derby-10.3.2.1\lib\derbytools.jar] 10.3.2.1 - (599110)
--
- Locale Information -
--
Reporter: Donatas Ciuksys
Assignee: A B
Priority: Blocker
Attachments: d3303_v1.patch, db.zip, ddl.sql
Derby throws ArrayIndexOutOfBoundsException when I try to execute SQL query
shown below.
This is a regression, since Derby 10.2.2.0 executes this query without
problems.
Attached are DDL statements to create DB tables, and database itself (with
data).
2008-01-08 12:32:34.461 GMT Thread[DRDAConnThread_5,6,derby.daemons] (XID =
1497), (SESSIONID = 0), (DATABASE = InventorizacijaDB), (DRDAID =
NF01.G46A-666250070078662256{1}), Failed Statement is: select
MAX(preke0_.BARKODAS) as col_0_0_, MAX(preke0_.PAVADINIMAS) as col_1_0_,
MAX(preke0_.KIEKIS) as col_2_0_, SUM(irasas1_.FAKTINIS_KIEKIS) as col_3_0_
from PREKE preke0_, IRASAS irasas1_, IRASU_BLOKAS irasubloka2_ where
irasas1_.IRASU_BLOKAS=irasubloka2_.ID and
preke0_.UNIKALUS_KODAS=irasas1_.UNIKALUS_KODAS and
irasubloka2_.INVENTORIZACIJA=? group by irasas1_.UNIKALUS_KODAS order by
abs(SUM(irasas1_.FAKTINIS_KIEKIS)-MAX(preke0_.KIEKIS)) DESC with 1 parameters
begin parameter #1: 1 :end parameter
java.lang.ArrayIndexOutOfBoundsException: 5
at org.apache.derby.impl.store.access.sort.MergeSort.compare(Unknown
Source)
at org.apache.derby.impl.store.access.sort.SortBuffer.insert(Unknown
Source)
at org.apache.derby.impl.store.access.sort.MergeInserter.insert(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3303) ArrayIndexOutOfBoundsException at MergeSort.compare
[
https://issues.apache.org/jira/browse/DERBY-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569449#action_12569449
]
Bryan Pendleton commented on DERBY-3303:
Hi Army, things lightened up a bit this afternoon so I had a look at the patch.
The comments are excellent! Thank you very much; they make it very clear.
Your change seems correct to me. The code is also considerably cleaner
by using visibleSize(), and reads better.
Here are a few suggestions; none are worth holding up the patch for.
- It might be nice to format your detailed comment for resolveAddedColumns()
as a true javadoc comment for that method (which currently has no javadoc),
rather than as an inline comment.
- I recalled from my investigations with DERBY-1861 that some of this code
gets exercised by various combinations of including * in the select list, and
using expressions in the order by list. So I tried a couple more test cases.
They didn't find any additional problems, but here they are anyway, in case you
think that they might add value to the regression suite:
select d3303.i as old_i, sum(d3303.k), d3303.* from d3303 group by k, i, j
order by j;
select d3303.i as old_i, sum(d3303.k), d3303.* from d3303 group by k, i, j
order by 4;
select d3303.i as old_i, sum(d3303.k), d3303.* from d3303 group by k, i, j
order by k+2;
+1 to commit.
ArrayIndexOutOfBoundsException at MergeSort.compare
---
Key: DERBY-3303
URL: https://issues.apache.org/jira/browse/DERBY-3303
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Environment: -- Java Information --
Java Version:1.6.0_03
Java Vendor: Sun Microsystems Inc.
Java home: D:\Programs\Java\jre1.6.0_03
Java classpath: derbytools.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: Donatas
Java user home: C:\Documents and Settings\Donatas
Java user dir: d:\java\derby-10.3.2.1\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[D:\java\derby-10.3.2.1\lib\derbytools.jar] 10.3.2.1 - (599110)
--
- Locale Information -
--
Reporter: Donatas Ciuksys
Assignee: A B
Priority: Blocker
Attachments: d3303_v1.patch, db.zip, ddl.sql
Derby throws ArrayIndexOutOfBoundsException when I try to execute SQL query
shown below.
This is a regression, since Derby 10.2.2.0 executes this query without
problems.
Attached are DDL statements to create DB tables, and database itself (with
data).
2008-01-08 12:32:34.461 GMT Thread[DRDAConnThread_5,6,derby.daemons] (XID =
1497), (SESSIONID = 0), (DATABASE = InventorizacijaDB), (DRDAID =
NF01.G46A-666250070078662256{1}), Failed Statement is: select
MAX(preke0_.BARKODAS) as col_0_0_, MAX(preke0_.PAVADINIMAS) as col_1_0_,
MAX(preke0_.KIEKIS) as col_2_0_, SUM(irasas1_.FAKTINIS_KIEKIS) as col_3_0_
from PREKE preke0_, IRASAS irasas1_, IRASU_BLOKAS irasubloka2_ where
irasas1_.IRASU_BLOKAS=irasubloka2_.ID and
preke0_.UNIKALUS_KODAS=irasas1_.UNIKALUS_KODAS and
irasubloka2_.INVENTORIZACIJA=? group by irasas1_.UNIKALUS_KODAS order by
abs(SUM(irasas1_.FAKTINIS_KIEKIS)-MAX(preke0_.KIEKIS)) DESC with 1 parameters
begin parameter #1: 1 :end parameter
java.lang.ArrayIndexOutOfBoundsException: 5
at org.apache.derby.impl.store.access.sort.MergeSort.compare(Unknown
Source)
at org.apache.derby.impl.store.access.sort.SortBuffer.insert(Unknown
Source)
at org.apache.derby.impl.store.access.sort.MergeInserter.insert(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
This message is
[jira] Issue Comment Edited: (DERBY-3299) Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns.
[ https://issues.apache.org/jira/browse/DERBY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569448#action_12569448 ] army edited comment on DERBY-3299 at 2/15/08 3:11 PM: - Attaching d3299_dropSharedConglom_v2.patch, which has been updated to account for the commit of d3299_caUtilMethods_v2.patch. This second version also has a minor change to the createNewBackingCongloms(...) method of AlterTableConstantAction--esp. _v2 removes an unnecessary parameter from that method. I've started derbyall with this patch applied; if all goes well and I hear no objections/feedback, I plan to commit it early next week (Mon or Tues PST). was (Author: army): Attaching d3299_dropSharedConglom_v2.patch, which has been updated to account for the commit of d3299_caUtilMethods_v2.patch. This second version also has a minor change to the createNewBackingCongloms(...) method of AlterTableConstantAction--esp. _v2 removes an unnecessary parameter from that method. I've started derbyall with this patch applied; if all goes well and I hear no objects/feedback, I plan to commit it early next week (Mon or Tues PST). Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns. --- Key: DERBY-3299 URL: https://issues.apache.org/jira/browse/DERBY-3299 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: A B Assignee: A B Priority: Minor Attachments: case_2.sql, d3299_caUtilMethods_v1.patch, d3299_caUtilMethods_v2.patch, d3299_createIxAction_v1.patch, d3299_dropSharedConglom_v1.patch, d3299_dropSharedConglom_v2.patch, d3299_tests_v1.patch, d3299_v1.patch When there are multiple constraints on a single table and the constraints have the same set of columns (in the same order), Derby tries to optimize things by re-using a single backing index for all of the relevant constraints. See the executeConstantAction() method of CreateIndexConstantAction.java (search for duplicate). But there is a bug in Derby where, if one of the constraints is unique and is dropped, the uniqueness attribute of the backing index is not updated accordingly. This means that uniqueness may be incorrectly enforced where it is not required. Take the following example (Case 2 from DERBY-2204): ALTER TABLE NEWORDERS ADD CONSTRAINT NEWORDERS_PK PRIMARY KEY(NO_W_ID, NO_D_ID, NO_O_ID); ALTER TABLE NEWORDERS ADD CONSTRAINT NO_O_FK FOREIGN KEY (NO_W_ID, NO_D_ID, NO_O_ID) REFERENCES ORDERS; For these statements Derby will use a single backing index for both the primary constraint NEWORDERS_PK and the foreign key constraint NO_O_FK. That backing index will be unique because the primary key must itself be unique. If later we drop the primary key: ALTER TABLE NEWORDERS DROP CONSTRAINT NEWORDERS_PK; then the backing index needs to be converted from a unique index to a non-unique index (because a foreign key is not inherently unique). But in Derby the uniqueness attribute remains unchanged, so attempts to insert a duplicate (NO_W_ID, NO_D_ID, NO_O_ID) row into NEWORDERS will fail with error 23505, when it should really succeed. I tried this out on 10.1.3.1 and the same behavior occurs there, so marking Affects versions for everything back to that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3299) Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns.
[ https://issues.apache.org/jira/browse/DERBY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A B updated DERBY-3299: --- Attachment: d3299_dropSharedConglom_v2.patch Attaching d3299_dropSharedConglom_v2.patch, which has been updated to account for the commit of d3299_caUtilMethods_v2.patch. This second version also has a minor change to the createNewBackingCongloms(...) method of AlterTableConstantAction--esp. _v2 removes an unnecessary parameter from that method. I've started derbyall with this patch applied; if all goes well and I hear no objects/feedback, I plan to commit it early next week (Mon or Tues PST). Uniqueness violation error (23505) occurs after dropping a PK constraint if there exists a foreign key on the same columns. --- Key: DERBY-3299 URL: https://issues.apache.org/jira/browse/DERBY-3299 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: A B Assignee: A B Priority: Minor Attachments: case_2.sql, d3299_caUtilMethods_v1.patch, d3299_caUtilMethods_v2.patch, d3299_createIxAction_v1.patch, d3299_dropSharedConglom_v1.patch, d3299_dropSharedConglom_v2.patch, d3299_tests_v1.patch, d3299_v1.patch When there are multiple constraints on a single table and the constraints have the same set of columns (in the same order), Derby tries to optimize things by re-using a single backing index for all of the relevant constraints. See the executeConstantAction() method of CreateIndexConstantAction.java (search for duplicate). But there is a bug in Derby where, if one of the constraints is unique and is dropped, the uniqueness attribute of the backing index is not updated accordingly. This means that uniqueness may be incorrectly enforced where it is not required. Take the following example (Case 2 from DERBY-2204): ALTER TABLE NEWORDERS ADD CONSTRAINT NEWORDERS_PK PRIMARY KEY(NO_W_ID, NO_D_ID, NO_O_ID); ALTER TABLE NEWORDERS ADD CONSTRAINT NO_O_FK FOREIGN KEY (NO_W_ID, NO_D_ID, NO_O_ID) REFERENCES ORDERS; For these statements Derby will use a single backing index for both the primary constraint NEWORDERS_PK and the foreign key constraint NO_O_FK. That backing index will be unique because the primary key must itself be unique. If later we drop the primary key: ALTER TABLE NEWORDERS DROP CONSTRAINT NEWORDERS_PK; then the backing index needs to be converted from a unique index to a non-unique index (because a foreign key is not inherently unique). But in Derby the uniqueness attribute remains unchanged, so attempts to insert a duplicate (NO_W_ID, NO_D_ID, NO_O_ID) row into NEWORDERS will fail with error 23505, when it should really succeed. I tried this out on 10.1.3.1 and the same behavior occurs there, so marking Affects versions for everything back to that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r627673 - /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/LangProcedureTest.java
I will soon make a checkin for the resultset from the procedure which shows that in trunk, after checkin 602991 for DERBY-1585, a procedure does not return a resultset if there was a rollbck inside the procedure with resultset creation before rollback. This behavior is different than what happens in 10.2 codeline. In 10.2, a procedure will return a *closed* resultset if there was a rollback inside the procedure. From Dan's earlier comment in this thread([Note a procedure does not return closed result sets]), it appears that trunk is behaving correctly and 10.2's behavior was incorrect. Mamta On 2/14/08, Mamta Satoor [EMAIL PROTECTED] wrote: Dan, you must have read my mind about dynamic resultset in my test case. I didn't on purpose add anything for that resultset because I am getting ready to file a jira entry for dynamic resultset and rollback inside java procedure. A rollback inside proc in 10.1 returns a closed dynamic resultset but the same thing in trunk returns a null object for dynamic resultset. I think I am very close to finding what commit caused this behavior. I need little more time to confirm that and then file a jira entry which will modify the test I have added Mamta On 2/14/08, Daniel John Debrunner [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: mamta Date: Wed Feb 13 22:24:50 2008 New Revision: 627673 URL: http://svn.apache.org/viewvc?rev=627673view=rev Log: DERBY-3304 and DERBY-3414 +s +.execute(create procedure procWithRollback(p1 int) parameter style JAVA READS SQL DATA dynamic result sets 1 language java external name 'org.apache.derbyTesting.functionTests.tests.lang.LangProcedureTest.rollbackInsideProc'); +drs1 = prepareCall(CALL procWithRollback(3)); +drs1.execute(); +rs = drs1.getResultSet(); This fixture never asserts that the procedure does not return any result sets. It fetches rs, but never does anything with it. Instead of fetching rs, it should be using: JDBC.assertNoMoreResults(s); There's a chance though that it may require DERBY-3404 to be fixed first. [Note a procedure does not return closed result sets] Dan.
[jira] Updated: (DERBY-2667) Create more robust junit TestRunner for running derby tests
[ https://issues.apache.org/jira/browse/DERBY-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjula Kutty updated DERBY-2667: - Attachment: DERBY-2667_diff_02_15.txt DERBY-2667_stat_02_15.txt Thanks for the comments Dan. Please review the new patch attached. I hope I answered all your comments in that patch. Please review and if everything looks good, please commit Create more robust junit TestRunner for running derby tests Key: DERBY-2667 URL: https://issues.apache.org/jira/browse/DERBY-2667 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.3.1.4 Reporter: Kathey Marsden Priority: Minor Attachments: DERBY-2667_diff_02_06.txt, DERBY-2667_diff_02_15.txt, DERBY-2667_stat_02_06.txt, DERBY-2667_stat_02_15.txt, JUnitMethodTrace.diff.txt, JUnitMethodTrace_Extra.diff.txt, MemRunner.java, TimeRunner.java Provide a more full featured TestRunner for Derby testing. junit.textui.TestRunner is not very robust. It does not for example print the tests as they run or print chained exceptions, create separate files for the full report and just failures. It would be great to have a standardized TestRunner that everyone uses. Perhaps someone already has one that they would like to contribute as a starter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: conn.rollback() in a procedure should not close the CallStatementResultSet - WAS Re: svn commit: r627673 - /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/LangPr
I will look at special handling of resultsets that do not return rows to stay open at the time of rollback unless the rollback is caused by an exception, in which case, we want to close all the resulsets whether they return rows or not. Mamta On 2/15/08, Daniel John Debrunner [EMAIL PROTECTED] wrote: Mamta Satoor wrote: I will soon make a checkin for the resultset from the procedure which shows that in trunk, after checkin 602991 for DERBY-1585, a procedure does not return a resultset if there was a rollbck inside the procedure with resultset creation before rollback. Thanks for finding the commit that caused it Mamta. Having made that change I had to look into why it changed the behaviour as that was not a intended part of the fix. DERBY-1585 fixed the issue that unprocessed dynamic result sets (e.g. in a trigger) were not closed until gc, leading to an error trying to drop a table due to an open result set. The fix (602991) changed it so that at the close of CallStatementResultSet any unprocessed dynamic result sets were closed. Thus the order is for a normal execution is: callStmtResultSet.open(); calls the Java method for the procedure method creates returns JDBC ResultSets embed statement processes dynamic result sets callStmtResultSet.close(); no dynamic results to close since embed statement handled them (and for a trigger embed statement is not involved so the callStmtResultSet.close closes any dynamic result sets) Now if the procedure's method calls rollback() then this is the order: callStmtResultSet.open(); calls the Java method for the procedure method creates sets JDBC ResultSets in parameter arrays rollback called() callStmtResultSet.close() close all dynamic result sets NEW (DERBY-1585) embed statement processes dynamic result sets callStmtResultSet.close(); no dynamic results to close since embed statement handled them So the change occurred because the rollback caused the close of the CallStatementResultSet to be called which now closes all outstanding dynamic result sets and clears all references to them, making them invisible to any following embed statement processing, resulting in no dynamic results being returned. Prior to 602991 even though the underlying language result of any dynamic jdbc result set was closed, the jdbc result set did not appear closed (actually due to something similar to DERBY-3404), thus embed statement processed it as an open result set and returned it. Any use on it failed (it was closed) as a different mechanism was used to check it was closed. So I understand why DERBY-1585 (602991) changed the behaviour but I don't think the complete logic is correct. Much like a commit in a procedure was incorrectly closing the CallStatementResultSet (recently fixed by Mamta) I believe the rollback should not be closing the CallStatementResultSet. It's still being used and thus should remain open. Now a rollback due to an exception that causes the CALL statement to throw an exception should close the CallStatementResultSet, but if the CALL statement is returning then its CallStatementResultSet should not be closed. Dan.
[jira] Updated: (DERBY-3303) ArrayIndexOutOfBoundsException at MergeSort.compare
[
https://issues.apache.org/jira/browse/DERBY-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-3303:
---
Attachment: d3303_v2.patch
Thank you very much for taking the time to review, Bryan. I appreciate it!
Your suggestions are great ones so I'm attaching a _v2 patch which incorporates
them. I did modify the comments a bit to try to be more accurate about what
resolveAddedColumn() really does--esp. for the example query, it doesn't
really look for a column corresponding to SUM(J), rather it looks for a
column corresponding to this.addedColumnOffset, which (in the old example)
ends up being SUM(J). I also changed the example to order by SUM(K) instead of
SUM(J) in hopes of making it clearer (since there are two SUM(J)s in the old
example).
Hopefully the new comments are not worse than the old ones...
Thanks again for the quick feedback!
ArrayIndexOutOfBoundsException at MergeSort.compare
---
Key: DERBY-3303
URL: https://issues.apache.org/jira/browse/DERBY-3303
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Environment: -- Java Information --
Java Version:1.6.0_03
Java Vendor: Sun Microsystems Inc.
Java home: D:\Programs\Java\jre1.6.0_03
Java classpath: derbytools.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: Donatas
Java user home: C:\Documents and Settings\Donatas
Java user dir: d:\java\derby-10.3.2.1\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[D:\java\derby-10.3.2.1\lib\derbytools.jar] 10.3.2.1 - (599110)
--
- Locale Information -
--
Reporter: Donatas Ciuksys
Assignee: A B
Priority: Blocker
Attachments: d3303_v1.patch, d3303_v2.patch, db.zip, ddl.sql
Derby throws ArrayIndexOutOfBoundsException when I try to execute SQL query
shown below.
This is a regression, since Derby 10.2.2.0 executes this query without
problems.
Attached are DDL statements to create DB tables, and database itself (with
data).
2008-01-08 12:32:34.461 GMT Thread[DRDAConnThread_5,6,derby.daemons] (XID =
1497), (SESSIONID = 0), (DATABASE = InventorizacijaDB), (DRDAID =
NF01.G46A-666250070078662256{1}), Failed Statement is: select
MAX(preke0_.BARKODAS) as col_0_0_, MAX(preke0_.PAVADINIMAS) as col_1_0_,
MAX(preke0_.KIEKIS) as col_2_0_, SUM(irasas1_.FAKTINIS_KIEKIS) as col_3_0_
from PREKE preke0_, IRASAS irasas1_, IRASU_BLOKAS irasubloka2_ where
irasas1_.IRASU_BLOKAS=irasubloka2_.ID and
preke0_.UNIKALUS_KODAS=irasas1_.UNIKALUS_KODAS and
irasubloka2_.INVENTORIZACIJA=? group by irasas1_.UNIKALUS_KODAS order by
abs(SUM(irasas1_.FAKTINIS_KIEKIS)-MAX(preke0_.KIEKIS)) DESC with 1 parameters
begin parameter #1: 1 :end parameter
java.lang.ArrayIndexOutOfBoundsException: 5
at org.apache.derby.impl.store.access.sort.MergeSort.compare(Unknown
Source)
at org.apache.derby.impl.store.access.sort.SortBuffer.insert(Unknown
Source)
at org.apache.derby.impl.store.access.sort.MergeInserter.insert(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2653: -- Attachment: derby-2653_proto_diff.txt Attached is a prototype of the change to forward the unimplemented methods to xxx(String sql, int autoGeneratedKeys). It is NOT for commit. The argument checking needs to be added, comments, and tests. I just thought the patch might ease discussion regarding the argument checking problem and make it clear that except for the argument checking these calls are the same as the existing autoGenerate keys methods. Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Priority: Minor Attachments: derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569506#action_12569506 ] Craig Russell commented on DERBY-3301: -- I'm convinced that this issue is resolved. I think it should stay open until a release containing the fix is made. Is that correct? Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569508#action_12569508 ] V.Narayanan commented on DERBY-3301: I think you can find more information about what to do here http://wiki.apache.org/db-derby/DerbyCommitProcess Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Assignee: Thomas Nielsen Fix For: 10.4.0.0 Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master-2.diff, derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, derby-3301-test-master.diff, derby-3301-test-master.stat, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY
[jira] Commented: (DERBY-3303) ArrayIndexOutOfBoundsException at MergeSort.compare
[
https://issues.apache.org/jira/browse/DERBY-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569510#action_12569510
]
Bryan Pendleton commented on DERBY-3303:
Patch 2 looks great, and changing that extra SUM(J) in the comments
does indeed make it clearer. I have no additional suggestions to offer.
ArrayIndexOutOfBoundsException at MergeSort.compare
---
Key: DERBY-3303
URL: https://issues.apache.org/jira/browse/DERBY-3303
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Environment: -- Java Information --
Java Version:1.6.0_03
Java Vendor: Sun Microsystems Inc.
Java home: D:\Programs\Java\jre1.6.0_03
Java classpath: derbytools.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: Donatas
Java user home: C:\Documents and Settings\Donatas
Java user dir: d:\java\derby-10.3.2.1\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[D:\java\derby-10.3.2.1\lib\derbytools.jar] 10.3.2.1 - (599110)
--
- Locale Information -
--
Reporter: Donatas Ciuksys
Assignee: A B
Priority: Blocker
Attachments: d3303_v1.patch, d3303_v2.patch, db.zip, ddl.sql
Derby throws ArrayIndexOutOfBoundsException when I try to execute SQL query
shown below.
This is a regression, since Derby 10.2.2.0 executes this query without
problems.
Attached are DDL statements to create DB tables, and database itself (with
data).
2008-01-08 12:32:34.461 GMT Thread[DRDAConnThread_5,6,derby.daemons] (XID =
1497), (SESSIONID = 0), (DATABASE = InventorizacijaDB), (DRDAID =
NF01.G46A-666250070078662256{1}), Failed Statement is: select
MAX(preke0_.BARKODAS) as col_0_0_, MAX(preke0_.PAVADINIMAS) as col_1_0_,
MAX(preke0_.KIEKIS) as col_2_0_, SUM(irasas1_.FAKTINIS_KIEKIS) as col_3_0_
from PREKE preke0_, IRASAS irasas1_, IRASU_BLOKAS irasubloka2_ where
irasas1_.IRASU_BLOKAS=irasubloka2_.ID and
preke0_.UNIKALUS_KODAS=irasas1_.UNIKALUS_KODAS and
irasubloka2_.INVENTORIZACIJA=? group by irasas1_.UNIKALUS_KODAS order by
abs(SUM(irasas1_.FAKTINIS_KIEKIS)-MAX(preke0_.KIEKIS)) DESC with 1 parameters
begin parameter #1: 1 :end parameter
java.lang.ArrayIndexOutOfBoundsException: 5
at org.apache.derby.impl.store.access.sort.MergeSort.compare(Unknown
Source)
at org.apache.derby.impl.store.access.sort.SortBuffer.insert(Unknown
Source)
at org.apache.derby.impl.store.access.sort.MergeInserter.insert(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
