[jira] Created: (DERBY-3367) Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate.
Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate. --- Key: DERBY-3367 URL: https://issues.apache.org/jira/browse/DERBY-3367 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.3.2.1 Reporter: Suresh Thalamati Attachments: derby.log Sort is not avoided even when the has an index on a the column being ordered, Repro: go.ddl: --- connect 'jdbc:derby:testdb;create=true'; create table t1 (i int, j int, vc varchar(30)); insert into t1 values (1, -1, 'minus one'); insert into t1 values (2, 2, 'two'), (3, 3, 'trois'), (3, -3, 'minus three'), (4, 4, 'four'); insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; create index ix on t1 (j); disconnect all; exit; go.sql: --- connect 'jdbc:derby:testdb'; get cursor c1 as 'select j, vc from t1 order by j asc'; next c1; close c1; get cursor c1 as 'select j, vc from t1 where j != -1 order by j asc'; next c1; close c1; -- After running go.sql, if you look at the derby.log file you'll see that the query with no predicate does an index scan and only has to read 1 row from disk before the cursor is closed. But the query _with_ a predicate does a table scan an has to read 3074 rows from disk, and sort them, just to return the first one in the result set. In the repro, it looks fast. But If the data is large, which was the case in my application. The table was: create table t2 (i int, j int, vc varchar(15000)); and loaded with 13000 rows. It takes almost minute to get the first row , for the query select j, vc from t1 where j != -1 order by j asc' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3367) Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate.
[ https://issues.apache.org/jira/browse/DERBY-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Thalamati updated DERBY-3367: Attachment: derby.log Derby log with the query plans. Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate. --- Key: DERBY-3367 URL: https://issues.apache.org/jira/browse/DERBY-3367 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.3.2.1 Reporter: Suresh Thalamati Attachments: derby.log Sort is not avoided even when the has an index on a the column being ordered, Repro: go.ddl: --- connect 'jdbc:derby:testdb;create=true'; create table t1 (i int, j int, vc varchar(30)); insert into t1 values (1, -1, 'minus one'); insert into t1 values (2, 2, 'two'), (3, 3, 'trois'), (3, -3, 'minus three'), (4, 4, 'four'); insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; create index ix on t1 (j); disconnect all; exit; go.sql: --- connect 'jdbc:derby:testdb'; get cursor c1 as 'select j, vc from t1 order by j asc'; next c1; close c1; get cursor c1 as 'select j, vc from t1 where j != -1 order by j asc'; next c1; close c1; -- After running go.sql, if you look at the derby.log file you'll see that the query with no predicate does an index scan and only has to read 1 row from disk before the cursor is closed. But the query _with_ a predicate does a table scan an has to read 3074 rows from disk, and sort them, just to return the first one in the result set. In the repro, it looks fast. But If the data is large, which was the case in my application. The table was: create table t2 (i int, j int, vc varchar(15000)); and loaded with 13000 rows. It takes almost minute to get the first row , for the query select j, vc from t1 where j != -1 order by j asc' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3367) Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate.
[ https://issues.apache.org/jira/browse/DERBY-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564205#action_12564205 ] Suresh Thalamati commented on DERBY-3367: - Thanks for your comments, Mike. I am not looking for Derby to optimize time to return the first row, The application needs all the rows , returned by the query. But it process the rows as it gets and shows results iteratively to the user. Because of sorting, it takes time to get the first row also , which makes it look as of the application is hung. My observation was, even in IJ , selecting all the rows without the != -1 qualifier was faster than with the qualifier. I was also surprised it used index without the qualifier., but not with the qualifier. It turns out to be good decision by the optimizer , if the sorting is external and spilling to disk, when data size is large. Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate. --- Key: DERBY-3367 URL: https://issues.apache.org/jira/browse/DERBY-3367 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.3.2.1 Reporter: Suresh Thalamati Attachments: derby.log Sort is not avoided even when the has an index on a the column being ordered, Repro: go.ddl: --- connect 'jdbc:derby:testdb;create=true'; create table t1 (i int, j int, vc varchar(30)); insert into t1 values (1, -1, 'minus one'); insert into t1 values (2, 2, 'two'), (3, 3, 'trois'), (3, -3, 'minus three'), (4, 4, 'four'); insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; create index ix on t1 (j); disconnect all; exit; go.sql: --- connect 'jdbc:derby:testdb'; get cursor c1 as 'select j, vc from t1 order by j asc'; next c1; close c1; get cursor c1 as 'select j, vc from t1 where j != -1 order by j asc'; next c1; close c1; -- After running go.sql, if you look at the derby.log file you'll see that the query with no predicate does an index scan and only has to read 1 row from disk before the cursor is closed. But the query _with_ a predicate does a table scan an has to read 3074 rows from disk, and sort them, just to return the first one in the result set. In the repro, it looks fast. But If the data is large, which was the case in my application. The table was: create table t2 (i int, j int, vc varchar(15000)); and loaded with 13000 rows. It takes almost minute to get the first row , for the query select j, vc from t1 where j != -1 order by j asc' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[
https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504943
]
Suresh Thalamati commented on DERBY-700:
I agree with Dan, getLockedFile() is confusing and should not be added
to the storage factory interfaces , if it can be avoided or have better
comments.
Just thought I will take a moment and explain, why in the first place
I added this method, I hope it will help in finding an alternative solution
or make the interface better.
I was testing and developing my solution on Windows. When I
first implemented without adding the getLockedFile() method, by
just getting the RandomAccessFile using StorageFile.getRandomAccessFile(),
after it is locked. I was hitting the error , java.io.IOException:
The process cannot access the file because another process has locked a
portion of the file. When it write UUID to the dbex.lck file.
After bit of debugging realized , I need access to the same
RandomAccesFile, that is used to the get the lock. So I simply
added the getLockedFile, which just return the same RandomAccessFile,
that is used to get the file lock.
public class writeLock {
public static void main(String[] args) throws Exception
{
File lf = new File(dbex.lck);
RandomAccessFile raf1 = new RandomAccessFile(lf, rw);
FileChannel fc = raf1.getChannel();
FileLock lock = fc.tryLock();
// attempt to write to locked file using another
//
RandomAccessFile raf2 = new RandomAccessFile(lf , rw);
// the following write is failing on windows.
raf2.writeChars(Derby is great );
}
}
For example , in the above code. Last write will fail with the error:
Exception in thread main java.io.IOException: The process cannot access the
file because another process has locked a portion of the file.
I did not verify, if this is the case in the non-window environment too. This
fix is mainly for non-window environment, so If on other platforms this is
not issue then the getLockedFile() can be replaced with the
StorageFile.getRandomAccesFile(). My concern is, How to confirm all
non-window environments will not give the above error.
First I thought of putting the new intraJVM lock code in the storage
factory, where getExclusiveFileLock() is implemented, For me
It looked worse alternative too getLockedFile() method, because then
getExlusiveFileLock() method semantics gets more confusing.
Another solution I was thinking that may work without adding the
*getLockedFile() is to use the range lock. like FileLock lock =
fc.tryLock(0, 10 ,false), and write to the file after the 10th byte.
This may need a new method getExclusiveLock() , which takes range.
May be simple solution is to add a new call, getExclusiveFileLock()
method that takes RandomAcceesFile as the argument.
To start with the reason we are in this mess is the getExclusiveLock()
implementation is not matching the way java interfaces work. Ideally
store code should hold on to the RandomAccessFile used for the lock,
not the storage factory implementraion. Ideally StorageRandomAccessFile
should give handle to the StorageFileChannel, which has the tryLock()
method, that returns FileLock.
Thanks
-suresh
Derby does not prevent dual boot of database from different classloaders on
Linux
-
Key: DERBY-700
URL: https://issues.apache.org/jira/browse/DERBY-700
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.2.1
Environment: ava -version
java version 1.4.2_08
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Priority: Critical
Fix For: 10.3.0.0
Attachments: DERBY-700.diff, DERBY-700.stat,
derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, derby-700_diff.txt,
derby-700_stat.txt, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff,
DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat,
derby-700_with_NPE_fix_diff.txt, derby-700_with_NPE_fix_stat.txt, derby.log,
derby700_singleproperty_v1.diff, derby700_singleproperty_v1.stat,
DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2,
releaseNote.html
Derby does not prevent dual boot from two different classloaders on Linux.
To reproduce run the program DualBootRepro with no derby jars in your
classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can
change the location by changing the DERBY_LIB_DIR variable.
On Linux the output is:
$java -cp . DualBootRepro
Loading derby from file:10.1.2.1/derby.jar
10.1.2.1/derby.jar
Booted
[jira] Updated: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati updated DERBY-378:
---
Fix Version/s: 10.3.0.0
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Fix For: 10.3.0.0
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, derby378_5.diff, derby378_6.diff, iexlobs.txt, iexlobs_v1.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati resolved DERBY-378.
Resolution: Fixed
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Fix For: 10.3.0.0
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, derby378_5.diff, derby378_6.diff, iexlobs.txt, iexlobs_v1.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498050 ] Suresh Thalamati commented on DERBY-700: [ Show » ] Kathey Marsden [22/May/07 03:22 PM] Thanks Suresh for the patch! I was wondering, why do we need setContextClassLoader privileges for derby.jar with the change? I must have added that permission while debugging to run the test under security manager. Only security permission that is required for derby.jar is read/write of derby.storage.jvmInstanceID property. Thanks for for volunteering to fix the bug, Kathey. . Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: https://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Assigned To: Kathey Marsden Priority: Critical Attachments: DERBY-700.diff, DERBY-700.stat, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.stat, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2 Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2527) Add documentation for import/export of LOBS and other binary data types.
[ https://issues.apache.org/jira/browse/DERBY-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497107 ] Suresh Thalamati commented on DERBY-2527: - Thanks for addressing my comments, Laura. I read through your comments, looks like you need my input only for this one: We still need an example for SYSCS_UTIL.SYSCS_EXPORT_QUERY_LOBS_TO_EXTFILE Yes, it is similar to other SYSCS_EXPORT_QUERY procedures, But I agree with you it will good to have an example for this one too. Example exporting data from a query, using a separate export file for the LOB data The following example shows how to export employee data in department 20 from the STAFF table in a sample database to the main file staff.del and the lob data to the file pictures.dat. CALL SYSCS_UTIL.SYSCS_EXPORT_QUERY_LOBS_TO_EXTFILE( 'SELECT * FROM STAFF WHERE dept=20', 'c:\data\staff.del', ',','','UTF-8','c:\data\pictures.dat'); Add documentation for import/export of LOBS and other binary data types. --- Key: DERBY-2527 URL: https://issues.apache.org/jira/browse/DERBY-2527 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Assigned To: Laura Stewart Attachments: derby2527_1.diff, derbytools.pdf, derbytools.pdf, iexlobs_v1.txt, refderby.pdf, refderby.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2527) Add documentation for import/export of LOBS and other binary data types.
[ https://issues.apache.org/jira/browse/DERBY-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497112 ] Suresh Thalamati commented on DERBY-2527: - Thanks Laura, I reviewed the import/export related sections in the attached pdf files, changes looks good. Please commit the changes. Some Minor things I noticed when I was reading through the doc again : Derby tools Guide : 1) On Page 46 : It says , in the second section : The import and export procedures read and write only text files not true any more , import/export writes and reads binary data from the external lob file. Please remove that sentence or change it to the following : The import and export procedures read and write only text files, except when blob data is imported or exported using an external file. 2) on Page 47 : section :Bulk import and export requirements and considerations: Restrictions on delimiters You cannot specify Hex decimal characters (0-9, a-f, A-F) as delimiters for the import and export procedures you may want to remove the above , I don't want users to think that is the only delimiter restriction. This restriction is already listed under File format for input and output on page page 49 :( Delimiters cannot be hex decimal characters (0-9, a-f, A-F).) along with other delimiter restrictions. 3) I really like the way you listed procedures. One minor thing I noticed is : a) On page 50 : 1. Choose the correct procedure for the type of import that you want to perform: and For examples using these procedures, see Examples of bulk import and export. Derby Tools and Utilities Guide 52 looks out of place. you may want to have heading as : Import Procedures and the below/above the table , write something like: Choose the correct procedure for the type of import that you want to perform from the table. For examples using these procedures, see Examples of bulk import and export.Derby Tools and Utilities Guide b) on page 52 , please do the same for export procedures. Derby Reference Guide : On page 126: SYSCS_UTIL.SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE example: CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE( 'APP', 'STAFF', 'c:\data\staff.del', ', ', '', 'UTF-8', 'c:\data\pictures.dat') delete the space in the column delimiter parameter value : ', ' it shoud be just ',' Thanks -suresh Add documentation for import/export of LOBS and other binary data types. --- Key: DERBY-2527 URL: https://issues.apache.org/jira/browse/DERBY-2527 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Assigned To: Laura Stewart Attachments: derby2527_1.diff, derbytools.pdf, derbytools.pdf, iexlobs_v1.txt, refderby.pdf, refderby.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Thalamati updated DERBY-700: --- Attachment: derby700_singleproperty_v1.stat derby700_singleproperty_v1.diff Attached is a patch with partial implementation of the intra-jvm db lock mechanism to prevent users from running multiple instances of the same database using different class loaders in the same jvm. Existing solution already prevents users from running multiple instances across jvms. Although I have not assigned this issue to myself, have been working on this issue on/off for some time. But I don't have free cycles to work on this bug for the upcoming release. I am posting the patch with whatever work I have done sofar. If some one can enhance the attached patch and fix this issue, that will be great. Intra-jvm db lock is provided by using global derby specific jvm instance id. On a first boot of any derby database in a jvm, an UUID is generated and stored in a system property (derby.storage.jvmInstanceID). This id is written to the dbex.lck file when the database is booted. If the ID in the dbex.lck file and the current jvm id stored in the system property derby.storage.jvmInstanceID are same then the database is already booted, and an exception will be thrown and database will not be booted. On a database shutdown , an Invalid JVM id is written to the dbex.lck file, so that if the database booted again ID's will not be equal, which means database is not already booted, the database will be booted successfully. I am using the existing UUID factory in the derby to generate the derby jvm id. Synchronization is done by using the interned strings. Synchronization across the JVM is done on derby.storage.jvmInstanceID string. And Synchronization for a database is done on the database directory. This may need to be changed to a database name, because it may not be possible to get the canonical path always and it is necessary to synchronize on a string, that is unique to a database in a jvm. In my earlier proposed solution I mentioned about releasing the db locks using finalizer. After doing some testing , I realized there is no need to address unlocking the database on garbage collection, using the finalizer. My understanding is unless users shutdown the database rawStoreDaemon and antiGC thread will hold on to the resources and the classes will not be unloaded. So the only way users can boot an already booted database but not in use using another class loader instance in the same jvm is by doing a shutdown from the class loader that booted the database. If some thinks this is not true, please correct me. To do : 1) cleanup error handling on IOExceptions and add new message for the intra-jvm db lock. 2) Currently dataDirectory path string is is used for synchronization to prevent multiple boots of a database. This may need to be changed to the db name. 3) Make the classLoaderBootTest.java run under security manager. 4) Add test cases for booting different databases parallelly on different threads with different class loaders. May not be really required , because even booting a single database through different threads shoud test the same thing. But it may be better to add a test case, just to be safe! 5) Run the test with large number of threads. 6) Anything else I have forgotten ! Thanks -suresh Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: https://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Priority: Critical Attachments: DERBY-700.diff, DERBY-700.stat, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.stat, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2 Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED]
[jira] Created: (DERBY-2649) An unsuccessful boot attempt of an booted database can potentially delete files in the temp directory that are in use.
An unsuccessful boot attempt of an booted database can potentially delete files in the temp directory that are in use. --- Key: DERBY-2649 URL: https://issues.apache.org/jira/browse/DERBY-2649 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.2.2.0 Reporter: Suresh Thalamati Lock to prevent multi-jvm boot is acquired after the temp directory is cleaned up in BaseDataFileDirectory.java boot() method. Because lock is acquired later , an unsuceessfule boot attempt could potentiall delete file in the temp directory that are in use. See : BaseDataFileDirectory.java : boot() storageFactory = ps.getStorageFactoryInstance( true, dataDirectory, startParams.getProperty( Property.STORAGE_TEMP_DIRECTORY, PropertyUtil.getSystemProperty( Property.STORAGE_TEMP_DIRECTORY)), identifier.toANSIidentifier()); Above call to get the storage factory seems to cleanup the temp directory, and the method is invode before calling the the method that prevents multi-jvm boot of an database. if (!isReadOnly()) // read only db, not interested in filelock getJBMSLockOnDB(identifier, uf, dataDirectory); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491013 ] Suresh Thalamati commented on DERBY-2020: - Thanks for addressing my comments , Olav. The latest patch looks good. Change file option for syncing log file to disk from rws to rwd --- Key: DERBY-2020 URL: https://issues.apache.org/jira/browse/DERBY-2020 Project: Derby Issue Type: Improvement Components: Performance, Store Affects Versions: 10.3.0.0 Reporter: Olav Sandstaa Assigned To: Olav Sandstaa Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, jvmsyncbug_v3.diff, jvmsyncbug_v3.stat, no-disk-cache.png, rwd.diff, rwd.stat For writing the transaction log to disk Derby uses a RandomAccessFile. If it is supported by the JVM, the log files are opened in rws mode making the file system take care of syncing writes to disk. rws mode will ensure that both the data and the file meta-data is updated for every write to the file. On some operating systems (e.g. Solaris) this leads to two write operation to the disk for every write issued by Derby. This is limiting the throughput of update intensive applications. If we could change the file mode to rwd this could reduce the number of updates to the disk. I have run some simple tests where I have changed mode from rws to rwd for the Derby log file. When running a small numbers of concurrent client threads the throughput is almost doubled and the response time is almost halved. I will attach some graphs that show this when running a given number of concurrent tpc-b like clients. These graphs show the throughput when running with rws and rwd mode when the disk's write cache has been enabled and disabled. I am creating this Jira to have a place where we can collect information about issues both for and against changing the default mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2527) Add documentation for import/export of LOBS and other binary data types.
[ https://issues.apache.org/jira/browse/DERBY-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488505 ] Suresh Thalamati commented on DERBY-2527: - Thanks Laura. My comments are below for the questions you posted. 1) The phrase performs single inserts ... should that be performs single row inserts ??? yes. performs single row inserts is better. 2) In the list of arguments, there is this text on many of the parameters Passing a null will result in an error. The current text might be confusing since other parameters allow a NULL value. I propose that we change it to: Omitting this parameter or passing a NULL value will result in a error Is this new phrasing accurate? Omitting a parameter will result an error for all the system procedures. I think it is not necessary to explicitly say that for some cases. 3) I'm confused about the import examples. Are the insertColumns and columnIndexes arguments optional? No. There are required arguments when using SYSCS_UTIL.SYSCS_IMPORT_DATA(..) or SYSCS_UTIL.SYSCS_IMPORT_DATA_LOBS_FROM_EXTFILE(...) . They are not arguments for SYSCS_UTIL.SYSCS_IMPORT_TABLE() and SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE(..) My understanding of the doc in the tools guide is, user follows the syntax defined for the procedures and finds the explanation for the arguments in the Arguments to import procedure page( http://db.apache.org/derby/docs/10.2/tools/rtoolsimport64241.html) depending on what procedure he/she is using. If so, then we should state that in the topic the describes the arguments. If not, then the examples need to be updated. Please advise :-) If you find any examples, that are not correct. Please let me know, I will verify them. Add documentation for import/export of LOBS and other binary data types. --- Key: DERBY-2527 URL: https://issues.apache.org/jira/browse/DERBY-2527 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Assigned To: Laura Stewart Attachments: iexlobs_v1.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2527) Add documentation for import/export of LOBS and other binary data types.
[ https://issues.apache.org/jira/browse/DERBY-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488527 ] Suresh Thalamati commented on DERBY-2527: - #2 : I agree with you. Changging the sentence to Passing a NULL value will result in an error. makes it more clear. #3. I will post an example using SYSCS_UTIL.SYSCS_IMPORT_DATA_LOBS_FROM_EXTFILE(...) [ Add documentation for import/export of LOBS and other binary data types. --- Key: DERBY-2527 URL: https://issues.apache.org/jira/browse/DERBY-2527 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Assigned To: Laura Stewart Attachments: iexlobs_v1.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2527) Add documentation for import/export of LOBS and other binary data types.
[
https://issues.apache.org/jira/browse/DERBY-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487958
]
Suresh Thalamati commented on DERBY-2527:
-
Thanks for volunteering to write the documentation , Laura. My comments are
below for the questions you posted.
1) Regarding null arguments.
yes. if user passes null value for any of the argument for import/export
procedures ,
default value is used. If user passes null as argument for schema
name, current schema is used. Default value for for column delimiter
is comma (,) and the default value for character delimiter is double
quote(). Default for the codeset depends on the environment user has started
the jvm.
It might be better to have an example that does not have null, to be more
clear. Please use the following example instead of the ones in the spec.
CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE('APP','STAFF',
'c:\data\staff.del',',','','UTF-8', 'c:\data\pictures.dat');
CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE(
'APP','STAFF','c:\data\staff.del',',','','UTF-8',0);
2)Reading how to document definition of the procedures.
This is not my creativity, I have just been following the same format as
other ones already in the documentation.
Laur wrote:
SYSCS_UTIL.SYSCS_IMPORT_DATA (IN SCHEMANAME VARCHAR(128),
IN TABLENAME VARCHAR(128), IN INSERTCOLUMNS VARCHAR(32672),
IN COLUMNINDEXES VARCHAR(32672), IN FILENAME VARCHAR(32672),
IN COLUMNDELIMITER CHAR(1), IN CHARACTERDELIMITER CHAR(1),
IN CODESET VARCHAR(128), IN REPLACE SMALLINT)
The syntax should appear in the docs as:
SYSCS_UTIL.SYSCS_IMPORT_DATA(
SCHEMANAME, TABLENAME, INSERTCOLUMNS, COLUMNINDEXES, FILENAME,
COLUMNDELIMITER,
CHARACTERDELIMITER, CODESET, REPLACE
)
No. It can not be that simple. Type of the arguments needs to be documented.
IN is to indicate that it is an input parameter. Procedure can have
OUT or INOUT type parameters. I find the above definition useful , just
by looking at the syntax , I can set the correct parameters instead of reading
through the whole doc.
May be the current way of documenting is not the best approach. If you have
some ideas to improve it, please file a separate jira. May be others will
have some opinions.
Add documentation for import/export of LOBS and other binary data types.
---
Key: DERBY-2527
URL: https://issues.apache.org/jira/browse/DERBY-2527
Project: Derby
Issue Type: Improvement
Components: Documentation
Affects Versions: 10.3.0.0
Reporter: Suresh Thalamati
Assigned To: Laura Stewart
Attachments: iexlobs_v1.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati updated DERBY-378:
---
Attachment: iexlobs_v1.txt
updated the spec and added some notes for dcoumnentation.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, derby378_5.diff, derby378_6.diff, iexlobs.txt, iexlobs_v1.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2527) Add documentation for import/export of LOBS and other binary data types.
Add documentation for import/export of LOBS and other binary data types. --- Key: DERBY-2527 URL: https://issues.apache.org/jira/browse/DERBY-2527 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Attachments: iexlobs_v1.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2527) Add documentation for import/export of LOBS and other binary data types.
[ https://issues.apache.org/jira/browse/DERBY-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Thalamati updated DERBY-2527: Attachment: iexlobs_v1.txt updated version of spec and some notes for the documentation. Add documentation for import/export of LOBS and other binary data types. --- Key: DERBY-2527 URL: https://issues.apache.org/jira/browse/DERBY-2527 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Attachments: iexlobs_v1.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
[ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486434 ] Suresh Thalamati commented on DERBY-2020: - Thanks for working on this issue Olav. your latest patch jvmsyncbug_v2.diff looks good. couple of minor comments: 1) One thing that puzzled me is why are you creating a new file rwtest.tmp ? why can not the test be done on the current log file itself, by opening the log file in rws mode and then closing, before it is opened in the appropriate mode. That way you can avoid a creating a new file and deleting it. 2) And Also, there are these weird read only db state scenarios. For example if you attempt to create a file when the db is made read readonly by putting it in a jar, derby is ok as long as there are no transactions pending. If there any pending transaction we may not catch it any more, because jvmsyncError() method attempting to create a rwtest.tmp file very early, it may fail immediately on log factory boot and decide all is well to treat the database as READONLY. But it will be a inconsistent one. I think derby tests suites has a readonly test, but i am not sure it covers pending transaction error case. Change file option for syncing log file to disk from rws to rwd --- Key: DERBY-2020 URL: https://issues.apache.org/jira/browse/DERBY-2020 Project: Derby Issue Type: Improvement Components: Performance, Store Affects Versions: 10.3.0.0 Reporter: Olav Sandstaa Assigned To: Olav Sandstaa Attachments: disk-cache.png, jvmsyncbug.diff, jvmsyncbug.stat, jvmsyncbug_v2.diff, jvmsyncbug_v2.stat, no-disk-cache.png, rwd.diff, rwd.stat For writing the transaction log to disk Derby uses a RandomAccessFile. If it is supported by the JVM, the log files are opened in rws mode making the file system take care of syncing writes to disk. rws mode will ensure that both the data and the file meta-data is updated for every write to the file. On some operating systems (e.g. Solaris) this leads to two write operation to the disk for every write issued by Derby. This is limiting the throughput of update intensive applications. If we could change the file mode to rwd this could reduce the number of updates to the disk. I have run some simple tests where I have changed mode from rws to rwd for the Derby log file. When running a small numbers of concurrent client threads the throughput is almost doubled and the response time is almost halved. I will attach some graphs that show this when running a given number of concurrent tpc-b like clients. These graphs show the throughput when running with rws and rwd mode when the disk's write cache has been enabled and disabled. I am creating this Jira to have a place where we can collect information about issues both for and against changing the default mode for writing to log files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[
https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484998
]
Suresh Thalamati commented on DERBY-700:
Thanks a lot for summarizing the problems and possible solutions
for this issue, Mike. I think the timer base solution you mentioned
might work, but I am not comfortable with a timer based solution. As you
mentioned, users might complain about the background writes, and also
I think configuring N to the right value to differentiate false
negatives/positives boots going to be hard. It will depend on the load
and the machine configuration (no of cpus ) ..etc.
I was trying to find alternative solutions, without much success. Only
solution I could come up with involves using a system property. I
understand, earlier we discussed using the system properties and it was
decided as not a such a good idea. But considering there are NO other
better solutions found for this problem, so far. I was think having one
property to maintain a JVMID may not be so bad, user just need to give
security permission to set one property, i.e if what I
describe below actually works!
I would really appreciate any suggestions/feedback for this solution .
My understanding is a solution to this problem need to solve primarily
following three issues:
1) Maintaining a state that a database is already booted, if the database
if booted successfully.
2) Change the state to NOT_BOOTED, if it is not booted any more because of a
a) Shutdown of the database
b) Class loader that booted the db is garbage collected.
c) JVM exited.
3) synchronization across class loaders.
Pseudo code below that attempts to solve this problems by making the
following Assumptions :
1) It is ok to use ONE system property derby.storage.jvmid to identify
a jvm instance id.
2) It is ok to use interned strings to synchronize across class loader.
3) It is ok to call getCanonicalPath(), i think this may require permission
for user.dir property if it is not already required. Other solution
may be to assign an ID string on create of the DB and user that for
DB level synchronization.
4) It is ok to rely on the class finalizer to cleanup db lock state,
when the database is NOT any more because the loader that booted
the database is garbage collected.
/*
Pseudo code to lock the DB to prevent multiple instance of a database running
concurrently through class loaders in a single instance of jvm or
multiple instance of jvm.
Note: Following code class is in a separate class just to understand it
as separate issue , this code should probably go into the
dataFactory class where current db-locking is done.
*/
Class DbLock {
private static final String DERYB_JVM_ID = derby.storage.jvmid;
private String dbCannonicalPath; // canonical of the db being booted.
private FileLock fileLock = null;
private boolean dbLocked = false;
DbLock (String dbCannonicalPath) {
this.dbCannonicalPath = dbCannonicalPath;
}
/*
* get a unique JVM ID
*/
private getJvmId () {
// synchronize across class loaders.
synchronize(DERYB_JVM_ID) {
jvmid = System.getProperty(DERYB_JVM_ID);
// if jvm id is not already exist, generate one
// and save it into the derby.storage.jvmid system
// property.
if (jvmid == null) {
//generate a new UUID based on the time and IP ..etc.
jvmid = generateJvmId()
System.setProperty(derby.storage.jvmid);
}
}
}
/*
* Lock the db, so that other class loader or
* another jvm won't be able to boot the same database.
*/
public lock_db_onboot(String dbCannonicalPath) {
// Get a file Lock on boot() ; // this already works
fileLock = getFileLock(dbex.lck);
if (lock == null) {
// if we don't get lock means , some other jvm already
// booted it throws ALREADY_BOOTED error.
throw ALREADY_BOOTED;
} else {
// file lock can be acquired even if the database is already
// booted by a different class loader. Check if another class
// loader has booted the DB. This is done by checking the
// JVMID written in the dbex.lck file. If the JVMID is same
// as what is stored in the system property,
// then database is already booted , throw the error.
currentJvmId = getJvmId();
synchronize(dbCannonicalPath) {
onDisk_JVM_ID = readIdFromDisk() ; // read ID from the
dbex.lck file.
if (OnDisk_JVM_ID == current_jvm_id )
throw (DATABASE IS ALREADY BOOTED);
else{
dbLocked = true;
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484550 ] Suresh Thalamati commented on DERBY-700: While reading comments for this issue yet again, noticed Rick mentioned long time ago , it might be possible to make Derby jdbc driver hold a state that is global to jvm, not specific to a class loader. Is that how it really works even if the user loads the driver using class loaders ? Basically , is it possible to make org.apache.derby.jdbc.EmbeddedDriver.java statically initialize an JVMID(a UUID) that can be accessed from any class loader ? Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: https://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Priority: Critical Attachments: DERBY-700.diff, DERBY-700.stat, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2 Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484586 ] Suresh Thalamati commented on DERBY-700: Thanks for confirming , Dan. I was referring to the commnet you noted. Looks like there is NO way to maintain an in-memory state that is global to JVM across class loader , other than using a system property. Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: https://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Priority: Critical Attachments: DERBY-700.diff, DERBY-700.stat, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2 Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483676
]
Suresh Thalamati commented on DERBY-378:
Thanks for your interest to document this issue Laura. Intially proposed spec
is attached to this jira (iexlobs.txt) , but it is out of date. I will update
the spec and post it in a day or two.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, derby378_5.diff, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati updated DERBY-378:
---
Attachment: derby378_6.diff
DERBY-378 (partial)
This patch adds code required to enable new system procedures added to
support import/export of lob data on hard upgrade from versions before
10.3. Added a new test case to the 10.3 upgrade test cases.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, derby378_5.diff, derby378_6.diff, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483798 ] Suresh Thalamati commented on DERBY-700: There does not seem to be any way to get process id info that can be used to fix this problem. Existing JVM enhancement requests filed to get process id info: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4250622 http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=7c75c6fc92c662c739fb11f620a4:YfiG?bug_id=4244896 It was interesting to reade these reports, other developers are finding it hard to generate unique id across jvms! Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: https://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Priority: Critical Attachments: DERBY-700.diff, DERBY-700.stat, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2 Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482927 ] Suresh Thalamati commented on DERBY-700: I took a quick looks at fixes for LUCENE-305 and LUCENE-635 , which are fixed now. I did not see any code that is attempting to solve locking within a jvm across class loaders boundaries. May be I am missing something ! Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: https://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Priority: Critical Attachments: DERBY-700.diff, DERBY-700.stat, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2 Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2465) Clob data type should use getCharacterStream() to read a column data from a VTI instead of getString().
[ https://issues.apache.org/jira/browse/DERBY-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482466 ] Suresh Thalamati commented on DERBY-2465: - Thanks Dan. Stack I am seeing is also similar to DERBY-2349. I will hold the fix for this issue until DERBY-2349 is fixed. Clob data type should use getCharacterStream() to read a column data from a VTI instead of getString(). - Key: DERBY-2465 URL: https://issues.apache.org/jira/browse/DERBY-2465 Project: Derby Issue Type: Improvement Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Attachments: derby.log, derby2465_v1.diff Currently clob data is read as String. This can consume lot of memory when lot of rows read from a VTI resultset. I think it would consume less memory if data is read using streams. org.apache.derby.iapi.types.SQLClob.java does not implement setValueFromResultSet() that is used by the VTI to read the data, it defaults to super class SQLChar.java implementation, which reads the data using getString(). One case I noticed the current implementation uses lot of memory is when doing import of clobs(DERBY-378). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482479
]
Suresh Thalamati commented on DERBY-378:
Thanks for the feedback Army Mike. I agree with both of you ,
LOBS_FROM_EXTFILE/LOBS_TO_EXTFILE sounds better than
LOBS_IN_EXTFILE. Unless someone else has a better
suggestions. New procedure names will be :
SYSCS_UTIL.SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE(..)
SYSCS_UTIL.SYSCS_EXPORT_QUERY_LOBS_TO_EXTFILE(..)
2)This patch implements following two new procedure that allow
import of large object data stored in a external file.
(for example exported previously using the above export procedures).
SYSCS_UTIL.SYSCS_IMPORT_DATA_LOBS_FROM_EXTFILE(...)
SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE(..)
--
One another other thing I was debating myself was whether
to use EXTFILE or SEPFILE. Sticking with EXTFILE,
SEPFILE does not seem any better.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, derby378_5.diff, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482500
]
Suresh Thalamati commented on DERBY-378:
Thanks for the feedback Laura. Incase of export EXTFILE is used
to indicate lob data is not stored in the main export file along with
other table data, but in a different file specified by the user. And incase of
import it indicates lobs data is in a different file, and the reference to
it is stored in the import file specified by the user.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, derby378_5.diff, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-1240) creating /restoring a db from backup using createFrom with log at different location copies the log from backup to the db dir also.
[
https://issues.apache.org/jira/browse/DERBY-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati resolved DERBY-1240.
-
Resolution: Fixed
creating /restoring a db from backup using createFrom with log at different
location copies the log from backup to the db dir also.
---
Key: DERBY-1240
URL: https://issues.apache.org/jira/browse/DERBY-1240
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.3.1, 10.2.1.6
Environment: WindowsXP/JDK142
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Priority: Minor
creating/restoring a database from a backup copy with exteral log location
copies the transaction log to the default location. db uses the external
location , but there is unnessary copy of transaction log at default
location.
connect 'wombat;create=true';
create table t1(a int );
insert into t1 values(15);
call SYSCS_UTIL.SYSCS_BACKUP_DATABASE('extinout/mybackup');
connect 'wombat;shutdown=true';
disconnect;
--- create a db from the backup using a different log location.
connect
'crwombat;createFrom=extinout/mybackup/wombat;logDevice=extinout/crwombatlog';
select * from t1;
--- If you loook under the crwombat dir you will find the log dir , it
should not be there because
-- transaction log is place st extinout/crwombatlog as specified in the
connection URL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2456) File stream is left open when an exception occurs while setting up a character stream for data export.
[ https://issues.apache.org/jira/browse/DERBY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482625 ] Suresh Thalamati commented on DERBY-2456: - Committed fix for this bug to trunk on revision 520684 File stream is left open when an exception occurs while setting up a character stream for data export. -- Key: DERBY-2456 URL: https://issues.apache.org/jira/browse/DERBY-2456 Project: Derby Issue Type: Bug Components: Tools Reporter: A B Assigned To: Suresh Thalamati Priority: Minor The JUnit test tools/ImportExportTest.java has been failing since it was first contributed with the following error: ImportExportTest:embeddedjunit.framework.AssertionFailedError: extinout\T1.dat at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:102) at org.apache.derbyTesting.junit.DropDatabaseSetup.access$000(DropDatabaseSetup.java:38) at org.apache.derbyTesting.junit.DropDatabaseSetup$1.run(DropDatabaseSetup.java:77) at java.security.AccessController.doPrivileged1(Native Method) at java.security.AccessController.doPrivileged(AccessController.java:287) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:74) at org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:107) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:23) 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) Also fails with the client, as well. Per the comment posted by Suresh to DERBY-2295, it looks like the cause of this failure is that the openFile() method of java/engine/org/apache/derby/impl/load/ExportWriteData.java does not close the file stream in cases where an invalid encoding is specified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2465) Clob data type should use getCharacterStream() to read a column data from a VTI instead of getString().
Clob data type should use getCharacterStream() to read a column data from a VTI instead of getString(). - Key: DERBY-2465 URL: https://issues.apache.org/jira/browse/DERBY-2465 Project: Derby Issue Type: Improvement Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Currently clob data is read as String. This can consume lot of memory when lot of rows read from a VTI resultset. I think it would consume less memory if data is read using streams. org.apache.derby.iapi.types.SQLClob.java does not implement setValueFromResultSet() that is used by the VTI to read the data, it defaults to super class SQLChar.java implementation, which reads the data using getString(). One case I noticed the current implementation uses lot of memory is when doing import of clobs(DERBY-378). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati updated DERBY-378:
---
Attachment: derby378_5.diff
DERBY-378 (partial)
This patch adds some code required to support import/exoprt of lob data.
1) Addded code to read clob data using getCharacterStream()
instead of getString() while importing clob data from an extern file.
(Note: Clobs are read using getString() until DERBY-2465 is fixed).
2) Made some code changes to make each lob column has it it's own file handle to
the lob file to read the data, otherwise streams can get corrupted when
there are more than one clob/blob type column in the table.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, derby378_5.diff, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2456) File stream is left open when an exception occurs while setting up a character stream for data export.
[ https://issues.apache.org/jira/browse/DERBY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Thalamati reassigned DERBY-2456: --- Assignee: Suresh Thalamati File stream is left open when an exception occurs while setting up a character stream for data export. -- Key: DERBY-2456 URL: https://issues.apache.org/jira/browse/DERBY-2456 Project: Derby Issue Type: Bug Components: Tools Reporter: A B Assigned To: Suresh Thalamati Priority: Minor The JUnit test tools/ImportExportTest.java has been failing since it was first contributed with the following error: ImportExportTest:embeddedjunit.framework.AssertionFailedError: extinout\T1.dat at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:102) at org.apache.derbyTesting.junit.DropDatabaseSetup.access$000(DropDatabaseSetup.java:38) at org.apache.derbyTesting.junit.DropDatabaseSetup$1.run(DropDatabaseSetup.java:77) at java.security.AccessController.doPrivileged1(Native Method) at java.security.AccessController.doPrivileged(AccessController.java:287) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:74) at org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:107) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:23) 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) Also fails with the client, as well. Per the comment posted by Suresh to DERBY-2295, it looks like the cause of this failure is that the openFile() method of java/engine/org/apache/derby/impl/load/ExportWriteData.java does not close the file stream in cases where an invalid encoding is specified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2465) Clob data type should use getCharacterStream() to read a column data from a VTI instead of getString().
[ https://issues.apache.org/jira/browse/DERBY-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Thalamati updated DERBY-2465: Attachment: derby.log derby2465_v1.diff Following the similar code in the SQLBlob data type, I made small changes to SQLClob.java as in the attached patch to make clob datatype read using getCharacterStream(). When I ran the tests, lang/TriggerTest Failied with following error: 1) testTypesInActionStatement(org.apache.derbyTesting.functionTests.tests.lang.T riggerTest)ERROR XSDA7: Restore of a serializable or SQLData object of class , a ttempted to read more data than was originally stored I wonder if I am doing something stupid or just hit a bug ? Clob data type should use getCharacterStream() to read a column data from a VTI instead of getString(). - Key: DERBY-2465 URL: https://issues.apache.org/jira/browse/DERBY-2465 Project: Derby Issue Type: Improvement Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Attachments: derby.log, derby2465_v1.diff Currently clob data is read as String. This can consume lot of memory when lot of rows read from a VTI resultset. I think it would consume less memory if data is read using streams. org.apache.derby.iapi.types.SQLClob.java does not implement setValueFromResultSet() that is used by the VTI to read the data, it defaults to super class SQLChar.java implementation, which reads the data using getString(). One case I noticed the current implementation uses lot of memory is when doing import of clobs(DERBY-378). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2295) DRDAProtocolTest:clientjunit.framework.AssertionFailedError
[ https://issues.apache.org/jira/browse/DERBY-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481275 ] Suresh Thalamati commented on DERBY-2295: - Army , I think ImportExportTest failure you mentioned is not related to this issue. My guess is on a negative test case extinout\T1.dat file is not getting closed. When I disbaled the test case : ImportExportTest: testInvalidEncoding() , this test is not failing. I think in ExportWriteData.openFile() , when an exception occurs while setting up the character stream with an Invalide encoding , file stream is not being closed. You may want to file a separate Jira for this issue. DRDAProtocolTest:clientjunit.framework.AssertionFailedError --- Key: DERBY-2295 URL: https://issues.apache.org/jira/browse/DERBY-2295 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Environment: A) -- Java Information -- Java Version:1.5.0_05 Java Vendor: Sun Microsystems Inc. Java home: c:\Program Files\Java\jdk1.5.0_05\jre Java classpath: C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derby.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyclient.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbytools.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbynet.jar;C:\cygwin\home\os136789\Apache\Derby\db2jcc\lib\db2jcc.jar;C:\cygwin\home\os136789\Apache\Derby\db2jcc\lib\db2jcc_license_c.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyTesting.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyrun.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\tools\java\jakarta-oro-2.0.8.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_de_DE.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_es.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_fr.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_it.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_ja_JP.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_ko_KR.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_pt_BR.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_zh_CN.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyLocale_zh_TW.jar;C:\cygwin\home\os136789\Apache\Derby\trunk\tools\java\junit.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: os136789 Java user home: C:\Documents and Settings\os136789 Java user dir: C:\cygwin\export\home\tmp\os136789\testingDerby\CYGWIN_NT-5.1_i686-unknown\org.apache.derbyTesting.functionTests.suites.All java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derby.jar] 10.3.0.0 alpha - (503453:503454) [C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbytools.jar] 10.3.0.0 alpha - (503453:503454) [C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbynet.jar] 10.3.0.0 alpha - (503453:503454) [C:\cygwin\home\os136789\Apache\Derby\trunk\jars\insane\derbyclient.jar] 10.3.0.0 alpha - (503453:503454) [C:\cygwin\home\os136789\Apache\Derby\db2jcc\lib\db2jcc.jar] 2.4 - (17) [C:\cygwin\home\os136789\Apache\Derby\db2jcc\lib\db2jcc_license_c.jar] 2.4 - (17) -- B) JVM name: Java HotSpot(TM) Client VM JVM version: 1.5.0_07-b03 JVM vendor: Sun Microsystems Inc. JVM datamodel: 32-bit Reporter: Ole Solberg Assigned To: Daniel John Debrunner Priority: Minor Fix For: 10.3.0.0 Seen on windows only. There were 2 failures: 1) DRDAProtocolTest:clientjunit.framework.AssertionFailedError at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:96) at org.apache.derbyTesting.junit.DropDatabaseSetup.access$000(DropDatabaseSetup.java:34) at org.apache.derbyTesting.junit.DropDatabaseSetup$1.run(DropDatabaseSetup.java:71) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:68) at org.apache.derbyTesting.junit.DropDatabaseSetup.tearDown(DropDatabaseSetup.java:62) at junit.extensions.TestSetup$1.protect(TestSetup.java:22) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at
[jira] Commented: (DERBY-2456) File stream is left open when an exception occurs while setting up a character stream for data export.
[ https://issues.apache.org/jira/browse/DERBY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481395 ] Suresh Thalamati commented on DERBY-2456: - temporarily disabled the test case that I think is causing ImportExportTest.java fail due to this bug , on revision 518816. File stream is left open when an exception occurs while setting up a character stream for data export. -- Key: DERBY-2456 URL: https://issues.apache.org/jira/browse/DERBY-2456 Project: Derby Issue Type: Bug Components: Tools Reporter: A B Priority: Minor The JUnit test tools/ImportExportTest.java has been failing since it was first contributed with the following error: ImportExportTest:embeddedjunit.framework.AssertionFailedError: extinout\T1.dat at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:102) at org.apache.derbyTesting.junit.DropDatabaseSetup.access$000(DropDatabaseSetup.java:38) at org.apache.derbyTesting.junit.DropDatabaseSetup$1.run(DropDatabaseSetup.java:77) at java.security.AccessController.doPrivileged1(Native Method) at java.security.AccessController.doPrivileged(AccessController.java:287) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:74) at org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:107) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:23) 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) Also fails with the client, as well. Per the comment posted by Suresh to DERBY-2295, it looks like the cause of this failure is that the openFile() method of java/engine/org/apache/derby/impl/load/ExportWriteData.java does not close the file stream in cases where an invalid encoding is specified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati updated DERBY-378:
---
Attachment: derby378_4.stat
derby378_4.diff
DERBY-378 (partial)
This patch adds code to handles NULL (SQL NULL) data while
performing import/export of table with column types blob, clob.
Checks for invalid hex strings in the import file while performing
import into a table with Blob column. Import will throw an exception
if it detects any invalid hex strings in the import file for blob column.
Tests:
1) Added a new junit test ImportExportLobTest.java to
tests import/export of clobs and blob data.
2) Wrapped BufferInputStream/BufferedReader around the streams
used in BaseJDBCTestCase.java:assertEquals() methods to compare
clobs/blobs. Without buffering these assert method were really slow.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, derby378_4.diff,
derby378_4.stat, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2247) provide set methods for blob in embeded driver
[ https://issues.apache.org/jira/browse/DERBY-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480521 ] Suresh Thalamati commented on DERBY-2247: - While doing some testing I ran into the LOBStreamControl.java in the stack. Couple of minor questions. 1) LOBStreamControl.java : isValidPostion() if (pos tmpFile.length()) throw Util.generateCsSQLException( SQLState.BLOB_POSITION_TOO_LARGE, new Long(pos + 1)); isValidPosition() is called on most of the read/write. I think calling a file length call can be expensive for each read/write call. 2) Are blobs written to temp files for some special cases ? I was just using BaseJdbcTestCase.java: assertEquals(Blob b1, Blob b2) method in my test. It was triggering the writes to temp file through LOBStreamControl.java , is this expected ? provide set methods for blob in embeded driver -- Key: DERBY-2247 URL: https://issues.apache.org/jira/browse/DERBY-2247 Project: Derby Issue Type: Sub-task Components: JDBC Environment: all Reporter: Anurag Shekhar Assigned To: Anurag Shekhar Priority: Minor Attachments: derby-2247-followup.diff, derby-2247-v3-usingStoreFactory.diff, derby-2247-v4-usingStoreFactory.diff, derby-2247.diff, derby-2247v2-using_StoreFactory.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati updated DERBY-378:
---
Attachment: derby378_3.stat
derby378_3.diff
DERBY -378 (partial)
This patch checks for invalid hex strings in the import file
while performing import into a table with CHAR FOR BIT DATA,
VARCHAR FOR BIT DATA, LONG VARCHAR FOR BIT DATA data types.
Import will throw an exception if it detects any invalid hex
strings during import.
Tests:
Added a new junit test case to ImportExportBinaryDataTest.java
to test for the invalid hex strings in the import file.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, derby378_3.diff, derby378_3.stat, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478840
]
Suresh Thalamati commented on DERBY-378:
Thanks for taking time to review , Dan.
1) I see use of StringUtil.fromHexString() in the patch, but no use of
StringUtil.toHexString() in the patch. How does the exporting work?
Export calls Resultset.getString() method for these types also. getString()
method
return the data in hex format, by calling StringUtil.toHexString().
2) If the input to StringUtil.fromHexString() is malformed by its length not
being a multiple of two then null will be silently inserted. Should import
throw an exception here?
Good Catch. inserting nulls on malformed hex strings is bad. I will add a
a check for the return value from StringUtil.fromHexString() , and throw an
exception if it is null.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478862
]
Suresh Thalamati commented on DERBY-378:
Committed derby378_2.diff to trunk on revision 515708..
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati updated DERBY-378:
---
Attachment: derby378_2.stat
derby378_2.diff
DERBY -378 (partial)
This patch adds code required to support import/export of a table with
CHAR FOR BIT DATA, VARCHAR FOR BIT DATA, LONG VARCHAR FOR BIT DATA
data types. Data of this type of columns is exported to the main export
file as hex strings. On import data is also expected to be in hex strings
in the main export file for these type of columns. This patch also
disallows use of hex decimal characters (0-9 , a-f , A-F) as
delimiters for import/export procedures.
Maximum data length of these types is only 32700 ( 254 bytes for CHAR FOR
BIT DATA , 32,672 for VARCHAR FOR BIT DATA and 32700 LONG VARCHAR FOR BIT
DATA). Because max length allowed is less than 32k, I think providing
import/Export
using an external file for these types may not add much value. No external
file support will be provided for these types. It can be added later,
if some one thinks it is required.
Tests:
Added a new junit test to test the import/export of these binary types.
It would be great if someone can review this patch.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, derby378_2.diff,
derby378_2.stat, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475979
]
Suresh Thalamati commented on DERBY-378:
Each blob/clob goes into its own separate external file? Or all the
blobs/clobs go into a single external file?
[ Show » ] Bryan Pendleton [24/Feb/07 05:15 PM]
All the blobs/clobs go into a single external file.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476056
]
Suresh Thalamati commented on DERBY-378:
Committed derby_378.diff to trunk on revision 512109. If there are any
review comments related to this patch , I will address them in the future
patches for this issue.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
https://issues.apache.org/jira/browse/DERBY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Thalamati updated DERBY-378:
---
Attachment: derby378_1.stat
derby378_1.diff
DERBY -378 (partial)
This patch adds some code required to support import/export of table with
clob, blob(large objects) data types. Clob/Blobs data can be exported to
an external file that different from the main export file. Location of the
lob data in the external file will be written to the main export file.
When writing the lob data to an external file, no conversion is done for the
binary data , clob data will be written using the user specified code set.
1)This patch implements following two new procedure to support
exporting LOBS to an external file name:
SYSCS_UTIL.SYSCS_EXPORT_TABLE_LOBS_IN_EXTFILE(..)
SYSCS_UTIL.SYSCS_EXPORT_QUERY_LOBS_IN_EXTFILE(..)
2)This patch implements following two new procedure that allow
import of large object data stored in a external file.
(for example exported previously using the above export procedures).
SYSCS_UTIL.SYSCS_IMPORT_DATA_LOBS_IN_EXTFILE(...)
SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_IN_EXTFILE(..)
3) import/export of table with clob,blob types will also work
with single input/output file, using the exiting import/export
procedures. In this can binary data is converted into hex format before
exporting and the data hex is converted to binary on import.
Clob data is exported similar to other char types.
Tests: derbyall/junitall test suites passed on Windows XP/JDK142, except
for the known failures.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: https://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: derby378_1.diff, derby378_1.stat, iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2348) testProtocol(org.apache.derbyTesting.functionTests.tests.derbynet.NetHarnessJavaTest)j failed
testProtocol(org.apache.derbyTesting.functionTests.tests.derbynet.NetHarnessJavaTest)j failed -- Key: DERBY-2348 URL: https://issues.apache.org/jira/browse/DERBY-2348 Project: Derby Issue Type: Test Affects Versions: 10.3.0.0 Environment: This test failed on ibm142/ibm15. Reporter: Suresh Thalamati 3) testProtocol(org.apache.derbyTesting.functionTests.tests.derbynet.NetHarnessJavaTest)junit.framework.ComparisonFailure: Output at line 26 expected:.. but was:...9 SECMEC=... at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) at org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) 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 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 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 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 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 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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) 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.
[jira] Commented: (DERBY-2318) testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest) failed on weme6.1 jvm/
[ https://issues.apache.org/jira/browse/DERBY-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473807 ] Suresh Thalamati commented on DERBY-2318: - This test also failed on one of the iibm15 jvm runs: 5) testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest)junit.framework.AssertionFailedError: FAILED!! level difference not expected since streams are materialized. expected:50 but was:51 at org.apache.derbyTesting.functionTests.tests.lang.StreamsTest.testStreams(StreamsTest.java:125) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) 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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest) failed on weme6.1 jvm/ - Key: DERBY-2318 URL: https://issues.apache.org/jira/browse/DERBY-2318 Project: Derby Issue Type: Test Affects Versions: 10.3.0.0 Environment: Java Version:J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: c:\jartest\weme6.1 Reporter: Suresh Thalamati Assigned To: Myrna van Lunteren Priority: Minor Fix For: 10.3.0.0 Time: 1,021.188 There was 1 failure: 1) testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest)junit.framework.AssertionFailedError: FAILED!! level difference not expected since streams are materialized. expected:48 but was:49 at org.apache.derbyTesting.functionTests.tests.lang.StreamsTest.testStreams(StreamsTest.java:118) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) 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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) FAILURES!!! Tests run: 1285, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2342) convert importExport.java to junit
[
https://issues.apache.org/jira/browse/DERBY-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473861
]
Suresh Thalamati commented on DERBY-2342:
-
Thanks for converting this test to junit , Andrew. Patch looks good to me., I
don't know much about junit..
Just couple of trivial comments/questions.
In the old tests harness I thought the policy was test files shoud not be
accessed under priveleged blocks. In the new junit framework
is it necessary to add priveleged blocks to access test files also ?
some comments :
File :
++ java/testing/org/apache/derbyTesting/junit/BaseTestCase.java (working copy)
1)
+ assertEquals(f1, f2);
+ } catch (FileNotFoundException e) {
+ fail(FileNotFoundException in
assertEquals(File,File): + e.toString());
+ } catch (IOException e) {
+ fail(IOException in assertEquals(File,
File): + e.toString());
+ }
It might be better to throw the exception up or a print stack trace also.
If it ever fails on some platform , stacks will be helpful.
2)
+
+ return new Boolean(true);
Any reson for returning a Boolean object from the run() method ? I
thought you are actaully passing it up ,
but looks like it just getting ignored. May you should just return null.
+++
java/testing/org/apache/derbyTesting/functionTests/tests/tools/ImportExportTest.java
(revision 0)
1)
+ Derby - Class org.apache.derbyTesting.functionTests.tests.tools.importExport
-- Name is copyright notices is correct.
2)
+ ps.setString(3, (fromTable==null ? fromTable : extinout/ +
fromTable + .dat ));
support files exttinout /extin are hard coded in this test. May be you want
to use the methods defined in SupportFilesSetup class.
to access/create support files. p SupportFilesSetup : ublic static File
getReadOnly(String name) ..etc.
3) This test is easy to understand. you may want to add still some comments
to the test , especially the data verification case.
Thanks
-suresh
convert importExport.java to junit
--
Key: DERBY-2342
URL: https://issues.apache.org/jira/browse/DERBY-2342
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.3.0.0
Reporter: Andrew McIntyre
Assigned To: Andrew McIntyre
Fix For: 10.3.0.0
Attachments: derby-2342-v1.diff, derby-2342-v1.stat,
derby-2342-v2.diff
Convert org.apache.derbyTesting.functionTests.tests.tools.importExport to
junit. New test is called ImportExportTest.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-2318) testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest) failed on weme6.1 jvm/
[ https://issues.apache.org/jira/browse/DERBY-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Thalamati reopened DERBY-2318: - It is still failing on the ibm nightly result runs on weme6.1, with the same error. testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest) failed on weme6.1 jvm/ - Key: DERBY-2318 URL: https://issues.apache.org/jira/browse/DERBY-2318 Project: Derby Issue Type: Test Affects Versions: 10.3.0.0 Environment: Java Version:J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: c:\jartest\weme6.1 Reporter: Suresh Thalamati Assigned To: Daniel John Debrunner Priority: Minor Fix For: 10.3.0.0 Time: 1,021.188 There was 1 failure: 1) testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest)junit.framework.AssertionFailedError: FAILED!! level difference not expected since streams are materialized. expected:48 but was:49 at org.apache.derbyTesting.functionTests.tests.lang.StreamsTest.testStreams(StreamsTest.java:118) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) 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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) FAILURES!!! Tests run: 1285, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2325) lang/grantRevokeDDL.sql is failing on wctme5.7_foundation jvm ...
lang/grantRevokeDDL.sql is failing on wctme5.7_foundation jvm ...
--
Key: DERBY-2325
URL: https://issues.apache.org/jira/browse/DERBY-2325
Project: Derby
Issue Type: Test
Affects Versions: 10.2.2.1
Environment: Java Version:J2ME Foundation Specification v1.0
Java Vendor: IBM Corporation
Java home: c:\jartest\wctme5.7\ive
Java classpath:
c:/jartest/classes/derby.jar;c:/jartest/classes/derbyLocale_zh_TW.jar;c:/jartest/classes/derbyLocale_zh_CN.jar;c:/jartest/classes/derbyLocale_ru.jar;c:/jartest/classes/derbyLocale_pt_BR.jar;c:/jartest/classes/derbyLocale_pl.jar;c:/jartest/classes/derbyLocale_ko_KR.jar;c:/jartest/classes/derbyLocale_ja_JP.jar;c:/jartest/classes/derbyLocale_it.jar;c:/jartest/classes/derbyLocale_hu.jar;c:/jartest/classes/derbyLocale_fr.jar;c:/jartest/classes/derbyLocale_es.jar;c:/jartest/classes/derbyLocale_de_DE.jar;c:/jartest/classes/derbyLocale_cs.jar;c:/jartest/classes/derbytools.jar;c:/jartest/classes/derbynet.jar;c:/jartest/classes/derbyclient.jar;;c:/jartest/classes/derbyrun.jar;c:/jartest/classes/derbyTesting.jar;c:/jartest/classes/maps.jar;c:/jartest/classes/functionTests.jar;c:/jartest/classes/csext.jar;c:/jartest/tools/java/junit.jar;c:/jartest/tools/java/jndi/fscontext.jar
OS name: Windows 2000
OS architecture: x86
OS version: 5.0 build 2195 Service Pack 4
Java user name: cloudtest
Java user home: C:\Documents and Settings\cloudtest
Java user dir: C:\jartest\JarResults.2007-01-18\wctme5.7_foundation_derbyall
java.specification.name: J2ME Foundation Specification
java.specification.version: 1.0
- Derby Information
JRE - JDBC: J2ME - JDBC for CDC/FP 1.0
Reporter: Suresh Thalamati
Priority: Minor
*** Start: grantRevokeDDL jdkJ2ME Foundation Specification v1.0
derbyall:derbylang 2007-01-19 03:25:27 ***
3219 del
ij(USER1)
3219 add
ij(USER1) -- Another test for DERBY-1847: verify that columns field is
updated
-- correctly when adding a column to a table:
create table d1847_c (a int, b int, c int);
0 rows inserted/updated/deleted
ij(USER1) grant select (a) on d1847_c to first_user;
0 rows inserted/updated/deleted
ij(USER1) grant update (b) on d1847_c to second_user;
0 rows inserted/updated/deleted
ij(USER1) grant select (c) on d1847_c to third_user;
0 rows inserted/updated/deleted
ij(USER1) select c.grantee, c.type, c.columns from sys.syscolperms c,
sys.systables t
where c.tableid = t.tableid and t.tablename='D1847_C';
GRANTEE
||COLUMNS
--
FIRST_USER
|s|{0}
SECOND_USER
|u|{1}
THIRD_USER
|s|{2}
3 rows selected
ij(USER1) alter table d1847_c add column d int;
0 rows inserted/updated/deleted
ij(USER1) select c.grantee, c.type, c.columns from sys.syscolperms c,
sys.systables t
where c.tableid = t.tableid and t.tablename='D1847_C';
GRANTEE
||COLUMNS
--
FIRST_USER
|s|{0}
SECOND_USER
|u|{1}
THIRD_USER
|s|{2}
3 rows selected
ij(USER1)
Test Failed.
*** End: grantRevokeDDL jdkJ2ME Foundation Specification v1.0
derbyall:derbylang 2007-01-
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2326) testCurrentTimestamp(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest) is failing on ibm131 ..
testCurrentTimestamp(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest) is failing on ibm131 .. Key: DERBY-2326 URL: https://issues.apache.org/jira/browse/DERBY-2326 Project: Derby Issue Type: Test Affects Versions: 10.2.2.1 Environment: Java Version:1.3.1 Java Vendor: IBM Corporation Java home: C:\jartest\ibm131\jre Java classpath: c:/jartest/classes/derby.jar;c:/jartest/classes/derbyLocale_zh_TW.jar;c:/jartest/classes/derbyLocale_zh_CN.jar;c:/jartest/classes/derbyLocale_ru.jar;c:/jartest/classes/derbyLocale_pt_BR.jar;c:/jartest/classes/derbyLocale_pl.jar;c:/jartest/classes/derbyLocale_ko_KR.jar;c:/jartest/classes/derbyLocale_ja_JP.jar;c:/jartest/classes/derbyLocale_it.jar;c:/jartest/classes/derbyLocale_hu.jar;c:/jartest/classes/derbyLocale_fr.jar;c:/jartest/classes/derbyLocale_es.jar;c:/jartest/classes/derbyLocale_de_DE.jar;c:/jartest/classes/derbyLocale_cs.jar;c:/jartest/classes/derbytools.jar;c:/jartest/classes/derbynet.jar;c:/jartest/classes/derbyclient.jar;;c:/jartest/classes/derbyrun.jar;c:/jartest/classes/derbyTesting.jar;c:/jartest/classes/maps.jar;c:/jartest/classes/functionTests.jar;c:/jartest/classes/csext.jar;c:/jartest/tools/java/junit.jar;c:/jartest/tools/java/jndi/fscontext.jar OS name: Windows 2000 OS architecture: x86 OS version: 5.0 Java user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\jartest\JarResults.2007-02-09\ibm131_derbyall java.specification.name: Java Platform API Specification Reporter: Suresh Thalamati * Diff file derbyall/derbylang/_Suite.diff *** Start: _Suite jdk1.3.1 derbyall:derbylang 2007-02-09 20:30:58 *** 0 add ..F.. There was 1 failure: 1) testCurrentTimestamp(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:390 but was:0 FAILURES!!! Tests run: 36, Failures: 1, Errors: 0 Test Failed. *** End: _Suite jdk1.3.1 derbyall:derbylang 2007-02-09 20:32:34 *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1457) lang/triggerGeneral.sql fails intermittently
[ https://issues.apache.org/jira/browse/DERBY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472504 ] Suresh Thalamati commented on DERBY-1457: - This test seems to be failing more often than I expected for an intermittant failure. I noticed this today on ibm15. ERROR 38000: The exception 'java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction.' was thrown while evaluating an expression. ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. ij -- Derby-85: It turns out that if a table t1 exists in a non-default schema lang/triggerGeneral.sql fails intermittently Key: DERBY-1457 URL: https://issues.apache.org/jira/browse/DERBY-1457 Project: Derby Issue Type: Test Components: Regression Test Failure Affects Versions: 10.2.1.6, 10.3.0.0 Environment: - IBM wsdd5.6 j9_13 - IBM 142: java version 1.4.2_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode) -ibm 1.5 Reporter: Deepa Remesh Priority: Minor This failure seems to be intermittent. The diff is: *** Start: triggerGeneral jdk1.3.1 subset - 2.1 derbyall:derbylang 2006-06-26 09:18:19 *** 941 del DERBY-388 Test Passed. 941a941,950 ERROR 38000: The exception 'SQL Exception: A SAVEPOINT with the passed name already exists in the current transaction.' was thrown while evaluating an expression. ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. ij -- Derby-85: It turns out that if a table t1 exists in a non-default schema -- and the default schema (e.g., SOMEUSER) doesn't exist yet (because no -- objects have been created in that schema), then attempts to create a -- trigger on t1 using its qualified name will lead to a null pointer -- exception in the Derby engine. connect 'wombat;user=someuser'; ij(CONNECTION1) autocommit off; ij(CONNECTION1) create table myschema.mytable (i int); 943,951d951 ij -- Derby-85: It turns out that if a table t1 exists in a non-default schema -- and the default schema (e.g., SOMEUSER) doesn't exist yet (because no -- objects have been created in that schema), then attempts to create a -- trigger on t1 using its qualified name will lead to a null pointer -- exception in the Derby engine. connect 'wombat;user=someuser'; ij(CONNECTION1) autocommit off; ij(CONNECTION1) create table myschema.mytable (i int); 0 rows inserted/updated/deleted Test Failed. *** End: triggerGeneral jdk1.3.1 subset - 2.1 derbyall:derbylang 2006-06-26 09:18:52 *** Stack trace of failure is: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at java.lang.Throwable.init(Throwable.java) at java.lang.Throwable.init(Throwable.java) at org.apache.derby.iapi.error.StandardException.init(StandardException.java:83) at org.apache.derby.iapi.error.StandardException.init(StandardException.java:72) at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:294) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Xact.java:1420) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(RAMTransaction.java:1997) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(GenericStatementContext.java:257) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:110) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:277) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(UpdateResultSet.java:825) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:288) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516) at org.apache.derbyTesting.functionTests.tests.lang.userDefMethods.derby388(userDefMethods.java:137) at org.apache.derby.exe.ac46a08075x010cx1122x5cc3x187d3624a5.g0(Unknown Source) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:199) at
[jira] Created: (DERBY-2318) testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest) failed on weme6.1 jvm/
testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest) failed on weme6.1 jvm/ - Key: DERBY-2318 URL: https://issues.apache.org/jira/browse/DERBY-2318 Project: Derby Issue Type: Test Affects Versions: 10.3.0.0 Environment: Java Version:J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: c:\jartest\weme6.1 Reporter: Suresh Thalamati Priority: Minor Time: 1,021.188 There was 1 failure: 1) testStreams(org.apache.derbyTesting.functionTests.tests.lang.StreamsTest)junit.framework.AssertionFailedError: FAILED!! level difference not expected since streams are materialized. expected:48 but was:49 at org.apache.derbyTesting.functionTests.tests.lang.StreamsTest.testStreams(StreamsTest.java:118) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) 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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) FAILURES!!! Tests run: 1285, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2117) Intermittent failure in lang/compressTable.sql
[ https://issues.apache.org/jira/browse/DERBY-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470396 ] Suresh Thalamati commented on DERBY-2117: - I notices the the same failure on a different jvm also : ** Start: compressTable jdkJ2ME Foundation Specification v1.1 derbyall:derbylang 2007-02-03 04:43:17 *** 1318 del T1 |1 |2 1318a1318 T1 |3 |0 Test Failed. Intermittent failure in lang/compressTable.sql -- Key: DERBY-2117 URL: https://issues.apache.org/jira/browse/DERBY-2117 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.0.0 Reporter: Knut Anders Hatlen lang/compressTable.sql has failed a number of times in the nightly regression tests. The diffs vary slightly: http://dbtg.thresher.com/derby/test/trunk15/jvm1.5/testing/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/476241-derbylang_diff.txt http://dbtg.thresher.com/derby/test/trunk15/jvm1.5/testing/testlog/CYGWIN_NT-5.1_i686-unknown/476241-derbyall_diff.txt * Diff file derbylang/derbylang/compressTable.diff *** Start: compressTable jdk1.5.0_07 derbylang:derbylang 2006-11-17 20:10:12 *** 1318 del T1 |1 |2 1318a1318 T1 |3 |0 Test Failed. *** End: compressTable jdk1.5.0_07 derbylang:derbylang 2006-11-17 20:10:39 *** http://dbtg.thresher.com/derby/test/trunk15/jvm1.5/testing/testlog/CYGWIN_NT-5.1_i686-unknown/476584-derbyall_diff.txt * Diff file derbyall/derbylang/compressTable.diff *** Start: compressTable jdk1.5.0_05 derbyall:derbylang 2006-11-18 23:07:44 *** 1318 del T1 |1 |2 1318a1318 T1 |2 |1 Test Failed. *** End: compressTable jdk1.5.0_05 derbyall:derbylang 2006-11-18 23:08:11 *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2107) Move page latching out of the lock manager
[ https://issues.apache.org/jira/browse/DERBY-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469575 ] Suresh Thalamati commented on DERBY-2107: - Hi Knut, I reviewed the latest patch, it looks good to be committed. I have only few minor questions/comments : 1) you may want to fix comments in void setExclusive(BaseContainerHandle requester) // because i) lock manager might assume latches are exclusive for // performance, ii) 2) + owner = requester; + requester.addObserver(this); It took me some time to understand how this works on an error cases scenarios, basically what happens if a thread after acquiring a latch errors out for some reason. My understanding is you are handling this cases by by putting the pages on the container observer list (requester.addObserver(this)). Please add some comments to why this page is added to observer list. 3) + + // just deadlock out if a transaction tries to double latch the + // page while not in abort comment is good. But , you may want to add some assertion or throw error here, if this case should not happen. 4) - /** Debugging, print slot table information */ - protected String slotTableToString() I don't know why you removed this method in this patch. May be this method is not used or not required. Occasionally I found these type of methods useful while debugging a page corruption to quickly dump page info with some minor changes to the code. 5) + // Expect notify from releaseExclusive(). + wait(); I was wondering , if the wait() method here should be time based to catch any infinite waits due to incorrectly missing release latch calls or you think it is going to be be unnecessarily expensive ? 5) Did you find the existing unit tests already tests latching methods ? or you are planning to write one. Thanks -suresh Move page latching out of the lock manager -- Key: DERBY-2107 URL: https://issues.apache.org/jira/browse/DERBY-2107 Project: Derby Issue Type: Improvement Components: Performance, Services, Store Affects Versions: 10.3.0.0 Reporter: Knut Anders Hatlen Assigned To: Knut Anders Hatlen Priority: Minor Attachments: derby-2107-1a.diff, derby-2107-1a.stat, derby-2107-1b.diff, derby-2107-1c.diff, derby-2107-1c.stat Latching of pages could be done more efficiently locally in store than in the lock manager. See the discussion here: http://thread.gmane.org/gmane.comp.apache.db.derby.devel/33135 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2284) OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change once written: was 0, now 80
[ https://issues.apache.org/jira/browse/DERBY-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Thalamati updated DERBY-2284: Attachment: derby.log OnlineBackupTest1.out error log files related to this test failure. OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change once written: was 0, now 80 - Key: DERBY-2284 URL: https://issues.apache.org/jira/browse/DERBY-2284 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.0.0 Environment: Windows 2000, IBM JDK 1.5 Reporter: Andrew McIntyre Attachments: derby.log, OnlineBackupTest1.out Saw this error in the nightlies last week, seems to be intermittant, filing this for tracking purposes: *** Start: OnlineBackupTest1 jdk1.5.0 storeall:storemore 2007-01-23 02:37:22 *** 5 del database shutdown properly 6 del Restored From the Backup 7 del Consistency Check is Done 8 del database shutdown properly 9 del End Online Backup Test1 9 add ERROR XJ001: Java exception: ': org.apache.derby.iapi.services.context.ShutdownException'. org.apache.derby.iapi.services.context.ShutdownException: ERROR 08003: No current connection. java.sql.SQLException: No current connection. ERROR XSDB3: Container information cannot change once written: was 0, now 80 ERROR XSDB3: Container information cannot change once written: was 0, now 80 at org.apache.derby.impl.store.raw.log.LogToFile.checkpException in thread main java.lang.Exception: BACKUP FAILED:Container information cannot change once written: was 0, now 80 oint(Unknown Source) Test Failed. *** End: OnlineBackupTest1 jdk1.5.0 storeall:storemore 2007-01-23 02:38:23 *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2144) Meta-data for Container could not be accessed when execute a SQL (select statement) for a View with 322 sub tables and views
[ http://issues.apache.org/jira/browse/DERBY-2144?page=comments#action_12459508 ] Suresh Thalamati commented on DERBY-2144: - I could not reporduce the problem on SuSE Linux 9.0 (i586) using ibm142 jvm. I saw similar error only when per process file limit in my environment was 1024,. once I fixed that query compiled without any problems. Error I saw with file descriptors are limited to 1024 in my environment. : ij Select * from vwDerbyBasePackage_derbygen_DerbyRepositoryObject67ceb178; ERROR XSDG3: Meta-data for Container org.apache.derby.impl.store.raw.data.RAFCon [EMAIL PROTECTED] could not be accessed ERROR XJ001: Java exception: '/home/suresht/work/tests/wombat/seg0/c16e1.dat (To o many open files): java.io.FileNotFoundException'. Meta-data for Container could not be accessed when execute a SQL (select statement) for a View with 322 sub tables and views Key: DERBY-2144 URL: http://issues.apache.org/jira/browse/DERBY-2144 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6 Environment: IBM JDK 1.4.2 with the Websphere 6.0.2.5 as the application server on Windows XP with service pack 2 for Derby 10.1.2.6 Reporter: Suraj Batuwana Attachments: DerbyIssue.zip I'm getting the following stack trace (in attached derby.log) when using embedded network server derby 10.2.1.6 I am getting following client side errors from my junit test cases as Error when executing query:com.ibm.websphere.ce.cm.StaleConnectionException: Meta-data for Container [EMAIL PROTECTED] could not be accessed junit.framework.AssertionFailedError: Error when executing query:com.ibm.websphere.ce.cm.StaleConnectionException: Meta-data for Container [EMAIL PROTECTED] could not be accessed Other than that I am seeing some of the errors from websphere server.log as [11/15/06 11:04:47:738 IST] 002c SystemErr R java.sql.SQLException: Failed to start database 'E:\Cloud_Branch\TestDB', see the next exception for details.DSRA0010E: SQL State = XJ040, Error Code = 40,000DSRA0010E: SQL State = XJ040, Error Code = 40,000 at sun.reflect.GeneratedConstructorAccessor243.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java(Compiled Code)) at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code)) at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapExceptionHelper(GenericDataStoreHelper.java:501) at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapException(GenericDataStoreHelper.java:544) at com.ibm.ws.rsadapter.spi.WSRdbDataSource.getPooledConnection(WSRdbDataSource.java:1037) at com.ibm.ws.rsadapter.spi.WSManagedConnectionFactoryImpl.createManagedConnection(WSManagedConnectionFactoryImpl.java:957) at com.ibm.ejs.j2c.poolmanager.FreePool.createManagedConnectionWithMCWrapper(FreePool.java:1551) Also when creating the data source in websphere I have used following classes as well Implementing class name org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource Implementing class name for XA org.apache.derby.jdbc.EmbeddedXADataSource Datasource Helper Class Name com.ibm.websphere.rsadapter.DerbyDataStoreHelper Driver Class Path c:\jars\derby-10.2.1.6.jar;c:\jars\derbynet-10.2.1.6.jar;c:\jars\derbytools-10.2.1.6.jar After that I was able to extract the issue from my application In my application there are 1000+ tables and 200+ views and each table has its own index. There is a particular view which uses 322 other tables and views like as create view vwDerbyBasePackage_derbygen_DerbyRepositoryObject67ceb178 (container_rid,derby_repos_object_id_derby,derby_created_by_user_derby,derby_creation_timestamp_derby,derby_modified_by_user_derby,derbymodificationtimestampxmet,derby_optimistic_lock_id_derby)AS select t.container_rid,t.derby_repos_object_id_derby,t.derby_created_by_user_derby,t.derby_creation_timestamp_derby,t.derby_modified_by_user_derby,t.derbymodificationtimestampxmet,t.derby_optimistic_lock_id_derby from DerbyBasePackage_derbygen_DerbyRepositoryObject67ceb178 t union all select
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
http://issues.apache.org/jira/browse/DERBY-378?page=comments#action_12458978 ]
Suresh Thalamati commented on DERBY-378:
Thanks for the input Dan. When I specify the column type for import VTI as
Types.BLOB , I got the following error :
The external virtual table interface does not support BLOB or CLOB columns.
''{0}'' column ''{1}''.
This error is coming from impl/sql/compile/FromVti.java
if( columnType == Types.BLOB || columnType == Types.CLOB)
throw
StandardException.newException(SQLState.LANG_VTI_BLOB_CLOB_UNSUPPORTED,
getVTIName(), rsmd.getColumnName( i));
I will check out triggers with BLOBS.
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: http://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
http://issues.apache.org/jira/browse/DERBY-378?page=comments#action_12458635 ]
Suresh Thalamati commented on DERBY-378:
related discussion on the derby-dev list:
http://www.nabble.com/%28DERBY-378%29-implementing--import-export-of-large-objects...-tf2515951.html#a7017509
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: http://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[
http://issues.apache.org/jira/browse/DERBY-378?page=comments#action_12458636 ]
Suresh Thalamati commented on DERBY-378:
Import uses VTI to import data into a table from a file. Just found out
that derby does not support CLOB/BLOB data types with VTI. Any one remember
why these types are not supported ?
Currently all the columns in the import file are treated as VARCHAR type and
cast them to the appropriate column type of the table, when the insert
statement is generated. For example to import into a table T4(
create table t4( a int , b char(100)) );
INSERT INTO T4(A, B) --DERBY-PROPERTIES insertMode=bulkInsert
SELECT cast(COLUMN1 AS INTEGER) , COLUMN2 from new org.apache.derby.impl.load
d.Import('c:/suresht/databases/emp.dat',null,null,null, 2 ) AS importvti ;
Clob types column can casted from VARCHAR type, performance may be bad but it
will work.
Problem with blob data type is, it can be casted from any other type.
I am kind of stuck on how to extract the binary data from an import file and
insert
into the table using the VTI, without VTI support for CLOB/BLOB types.
types.
Any ideas/suggestions ?
Thanks
-suresh
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: http://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2169) Schema does not exist exception for existing schema calling syscs_util.syscs_compress_table
[
http://issues.apache.org/jira/browse/DERBY-2169?page=comments#action_12458246 ]
Suresh Thalamati commented on DERBY-2169:
-
I think this procedure expects the scema name and the table name to be passed
to in upper cases , unless the table/schema were created as quoted identifiers.
you may want to try the following :
call syscs_util.syscs_compress_table('TEST','TEST, 0 );
Schema does not exist exception for existing schema calling
syscs_util.syscs_compress_table
---
Key: DERBY-2169
URL: http://issues.apache.org/jira/browse/DERBY-2169
Project: Derby
Issue Type: Bug
Affects Versions: 10.2.1.6
Environment: OS X, java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
Reporter: Dieter Wimberger
syscs_util.syscs_compress_table throws a schema does not exist exception
for an existing schema.
Call is made according to the documentation in the reference manual:
SYSCS_UTIL.SYSCS_COMPRESS_TABLE (IN SCHEMANAME VARCHAR(128),
IN TABLENAME VARCHAR(128), IN SEQUENTIAL SMALLINT)
Testcase using ij:
connect 'jdbc:derby:test;create=true';
create schema test;
create table test.test(id varchar(255));
insert into test.test values('test1');
insert into test.test values('test2');
call syscs_util.syscs_compress_table('test','test',0);
ERROR 38000: The exception 'java.sql.SQLException: Schema 'test' does not
exist' was thrown while evaluating an expression.
ERROR 42Y07: Schema 'test' does not exist
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2144) Meta-data for Container could not be accessed when execute a SQL (select statement) for a View with 322 sub tables and views
[ http://issues.apache.org/jira/browse/DERBY-2144?page=all ] Suresh Thalamati updated DERBY-2144: Assignee: (was: Suresh Thalamati) Suraj, This is a open-source project, Developers work voluntarily. I can not assign issues to any one except to my-self. If some one is interested and have time to work on this issue, they assign it themselves. Meta-data for Container could not be accessed when execute a SQL (select statement) for a View with 322 sub tables and views Key: DERBY-2144 URL: http://issues.apache.org/jira/browse/DERBY-2144 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6 Environment: IBM JDK 1.4.2 with the Websphere 6.0.2.5 as the application server on Windows XP with service pack 2 for Derby 10.1.2.6 Reporter: Suraj Batuwana Priority: Blocker Attachments: DerbyIssue.zip I'm getting the following stack trace (in attached derby.log) when using embedded network server derby 10.2.1.6 I am getting following client side errors from my junit test cases as Error when executing query:com.ibm.websphere.ce.cm.StaleConnectionException: Meta-data for Container [EMAIL PROTECTED] could not be accessed junit.framework.AssertionFailedError: Error when executing query:com.ibm.websphere.ce.cm.StaleConnectionException: Meta-data for Container [EMAIL PROTECTED] could not be accessed Other than that I am seeing some of the errors from websphere server.log as [11/15/06 11:04:47:738 IST] 002c SystemErr R java.sql.SQLException: Failed to start database 'E:\Cloud_Branch\TestDB', see the next exception for details.DSRA0010E: SQL State = XJ040, Error Code = 40,000DSRA0010E: SQL State = XJ040, Error Code = 40,000 at sun.reflect.GeneratedConstructorAccessor243.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java(Compiled Code)) at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code)) at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapExceptionHelper(GenericDataStoreHelper.java:501) at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapException(GenericDataStoreHelper.java:544) at com.ibm.ws.rsadapter.spi.WSRdbDataSource.getPooledConnection(WSRdbDataSource.java:1037) at com.ibm.ws.rsadapter.spi.WSManagedConnectionFactoryImpl.createManagedConnection(WSManagedConnectionFactoryImpl.java:957) at com.ibm.ejs.j2c.poolmanager.FreePool.createManagedConnectionWithMCWrapper(FreePool.java:1551) Also when creating the data source in websphere I have used following classes as well Implementing class name org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource Implementing class name for XA org.apache.derby.jdbc.EmbeddedXADataSource Datasource Helper Class Name com.ibm.websphere.rsadapter.DerbyDataStoreHelper Driver Class Path c:\jars\derby-10.2.1.6.jar;c:\jars\derbynet-10.2.1.6.jar;c:\jars\derbytools-10.2.1.6.jar After that I was able to extract the issue from my application In my application there are 1000+ tables and 200+ views and each table has its own index. There is a particular view which uses 322 other tables and views like as create view vwDerbyBasePackage_derbygen_DerbyRepositoryObject67ceb178 (container_rid,derby_repos_object_id_derby,derby_created_by_user_derby,derby_creation_timestamp_derby,derby_modified_by_user_derby,derbymodificationtimestampxmet,derby_optimistic_lock_id_derby)AS select t.container_rid,t.derby_repos_object_id_derby,t.derby_created_by_user_derby,t.derby_creation_timestamp_derby,t.derby_modified_by_user_derby,t.derbymodificationtimestampxmet,t.derby_optimistic_lock_id_derby from DerbyBasePackage_derbygen_DerbyRepositoryObject67ceb178 t union all select t0.container_rid,t0.derby_repos_object_id_derby,t0.derby_created_by_user_derby,t0.derby_creation_timestamp_derby,t0.derby_modified_by_user_derby,t0.derbymodificationtimestampxmet,t0.derby_optimistic_lock_id_derby from DerbyCore_derbygen_XQMAnnotationse07f3bbc t0 ... ... union all select
[jira] Commented: (DERBY-606) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
[
http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12456260 ]
Suresh Thalamati commented on DERBY-606:
derby606_impl-v5.diff :
This patch looks good to be committed. Did you run the regression tests ?
For some reason I can not apply this patch to my code-line.
Could you please recreate the patch and post it.
$ patch -i c:/temp/derby606_impl-v5.diff
patching file `java/engine/org/apache/derby/impl/store/raw/xact/Xact.java'
patching file `java/engine/org/apache/derby/impl/store/raw/data/CompressSpacePag
eOperation10_2.java'
patch: malformed patch at line 120: Index: java/engine/org/apache/derby/imp
l/store/raw/data/LoggableAllocActions.java
1) One minor thing I noticed is you did not update the MAX_ID_2 in the
following file :
Index: java/engine/org/apache/derby/iapi/services/io/StoredFormatIds.java
public static final int MAX_ID_2 =
(MIN_ID_2 + 464);
File derby606_upgrade-v5.diff :
As Bryan and others pointed out Derby supports upgrade from 10.1 to 10.3
also. This patch seems to incorrectly remove 10.1 to 10.3 upgrade test.
After your latest change to allow Compress on softupgrade , following error
check is not valid any more:
+ try {
+ checkDataToCase606(conn, 0, 104000, true);
+ } catch(SQLException sqle) {
+ passed = isExpectedException(sqle, XSLB1);
Now the above check is going to fail on softupgrade because of the derby-606
bug.
As I understand changes to upgrade is going to test :
1) Compress Log Record writes on compress operation.
2) On hard upgrade , derby-606 problem does not occur.
Following cases is not tested :
1) Replay of the old compress log record on softupgrade/hardupgrade (
readExternal() execution), because database is shutdown after each upgrade test
phase. This might be tricky to do because you need to simulate crash-recovery,
you can work on it separately if you are interested. Let's try to get the
current patches committed.
Thanks
-suresh
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
Key: DERBY-606
URL: http://issues.apache.org/jira/browse/DERBY-606
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.1.0
Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition
Reporter: Jeffrey Aguilera
Assigned To: Mayuresh Nirhali
Fix For: 10.3.0.0
Attachments: A606Test.java, derby606-v2.diff, derby606-v3.diff,
derby606_impl-v4.diff, derby606_impl-v5.diff, derby606_upgrade-v4.diff,
derby606_upgrade-v5.diff, derby606_v1.diff
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails with one of the following error
messages when applied to a very large table (2GB):
Log operation null encounters error writing itself out to the log stream,
this could be caused by an errant log operation or internal log buffer full
due to excessively large log operation. SQLSTATE: XJ001: Java exception: ':
java.io.IOException'.
or
The exception 'java.lang.ArrayIndexOutOfBoundsException' was thrown while
evaluating an expression. SQLSTATE: XJ001: Java exception: ':
java.lang.ArrayIndexOutOfBoundsException'.
In either case, no entry is written to the console log or to derby.log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-606) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
[
http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12454827 ]
Suresh Thalamati commented on DERBY-606:
Thanks for working on this issue. Patch looks good , i have only few minor
comments.
1) Two new classes CompressSpacePageOperation10_2.java and
CompressSpacePageOperation10_3.java may not be required. I think
CompressSpacePageOperation.java
can be modified to handle the new 10.3/10.2 behavior and create one new class
CompressSpacePageOperation10_2 that extends the CompressSpacePageOperation
and sets the old format id.
2) CompressSpacePageOperation10_2.java Copyright has a wrong class name.
Index:
java/engine/org/apache/derby/impl/store/raw/data/CompressSpacePageOperation10_2.java
+ Derby - Class org.apache.derby.impl.store.raw.data.ChainAllocPageOperation
3) Minor comment error in
Index: java/engine/org/apache/derby/iapi/store/raw/RawStoreFactory.java
+ /** Derby Store Minor Version (2) **/
+ public static final int DERBY_STORE_MINOR_VERSION_3= 3;
version number in the comment , should be 3.
4) Great work with tests. One minor nit :
When I looked first time , following change in the OnlineCompressTest.java,
got me confused.
+int[] test_cases = {104000};
+for (int i = 0; i test_cases.length; i++)
+{
+// first create new table and run the tests.
+createAndLoadLargeTable(conn, true, table_name, test_cases[i], 0);
+
I am sure you must have added it to try different no of rows to reproduce the
problem. Now that you know the no of of rows required to reproduce
the problem. It might be better to change the code to noRows= 104000
instead of test_cases; just to make it more clear.
5) tests/upgradeTests/Upgrade_10_2_10_3.java has to be disabled due to
DERBY-1135 bug , please see build.xml in this directory.
There is another Jira entry
(http://issues.apache.org/jira/browse/DERBY-1689) to add upgrade tests
for 10.2 to 102. If you would like to address the 10.2 to 10.3 upgrade
support in a separate patch, that is fine with me.
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
Key: DERBY-606
URL: http://issues.apache.org/jira/browse/DERBY-606
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.1.0
Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition
Reporter: Jeffrey Aguilera
Assigned To: Mayuresh Nirhali
Fix For: 10.3.0.0
Attachments: A606Test.java, derby606-v2.diff, derby606_v1.diff
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails with one of the following error
messages when applied to a very large table (2GB):
Log operation null encounters error writing itself out to the log stream,
this could be caused by an errant log operation or internal log buffer full
due to excessively large log operation. SQLSTATE: XJ001: Java exception: ':
java.io.IOException'.
or
The exception 'java.lang.ArrayIndexOutOfBoundsException' was thrown while
evaluating an expression. SQLSTATE: XJ001: Java exception: ':
java.lang.ArrayIndexOutOfBoundsException'.
In either case, no entry is written to the console log or to derby.log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-606) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
[
http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12455046 ]
Suresh Thalamati commented on DERBY-606:
Thanks for considering my suggestions. Extra check(if( !(this instanceof
CompressSpacePageOperation10_2) ) in the CompressSpacePageOperation.java
is ok. You need some kind of check in to correctly call the
writeExternal/readExternal. Only othe alternative I can think of is to
check for formatId instead of using the instanceof.
While reviewing the latest patches(derby606_impl-v4.diff and
derby606_upgrade-v4.diff ),
noticed you are disabling IN_PLACE_COMPRESS on soft-upgrade to 10.3, in my
view that is incorrect. If I understand correctly this bug happens only on
large data size and does not leave the database in the corrupt state.
I believe right thing to do is to use the old log record on soft-upgrade to
10.3 and allow compress. If you would like to be real nice to the users
then you can catch the bugs case and throw an error message, but I think it is
not required; users hitting the bug case first time on a a soft-upgrade is
almost zero probability.
Index:
java/engine/org/apache/derby/impl/store/raw/data/LoggableAllocActions.java
+ if(
t.getLogFactory().checkVersion(RawStoreFactory.DERBY_STORE_MAJOR_VERSION_10,
+
RawStoreFactory.DERBY_STORE_MINOR_VERSION_3,
+ CompressSpace operation on an existing
database) )
Above call throws an exception if version is not at the correct level, in this
case if not at 10.3. I think if you pass null for feature name , it will
just return true/false.
Please also fix the upgrade tests also, if you decide to allow compress on
soft-upgrade.
I am sorry for missing this in my previous review.
There is one major problem with the latest patch, it can make database
non-recoverable on upgrade from 10.2.
1) Formatid are incorrect for CompressSpacePageOperation10_2 and
CompressSpacePageOperation.
CompressSpacePageOperation should have the new format id and the
CompressSpacePageOperation10_2 should have the OLD one.
Related changes :
Index:
java/engine/org/apache/derby/impl/store/raw/data/CompressSpacePageOperation10_2.java
+
+ /**
+ Return my format identifier.
+ */
+ public int getTypeFormatId() {
+ return super.getTypeFormatId();
+ }
I am sure , you wanted it to return StoredFormatIds.LOGOP_COMPRESS10_2_SPACE;
and also :
Index: java/engine/org/apache/derby/iapi/services/io/RegisteredFormatIds.java
+ /* 465 */
org.apache.derby.impl.store.raw.data.CompressSpacePageOperation10_2,
That shoud have been
org.apache.derby.impl.store.raw.data.CompressSpacePageOperation and you
should change existing entry for compress to CompressSpacePageOperation10_2.
and the format id numbers should get changed also :
Index: java/engine/org/apache/derby/iapi/services/io/StoredFormatIds.java
public static final int LOGOP_COMPRESS_SPACE =
(MIN_ID_2 + 454);
+ /* org.apache.derby.impl.store.raw.data.CompressSpacePageOperation10_2
*/
+public static final int LOGOP_COMPRESS10_2_SPACE =
+(MIN_ID_2 + 465);
+
2) In the upgrade test , why you need to insert 104000 rows ? I think you
can produce the compress log record with less number of records and reduce
the test time.
+ try {
+ checkDataToCase606(conn, 0, 104000, true);
+ } catch(SQLException sqle) {
+ passed = isExpectedException(sqle, XSLB1);
+ }
Thanks
-suresh
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
Key: DERBY-606
URL: http://issues.apache.org/jira/browse/DERBY-606
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.1.0
Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition
Reporter: Jeffrey Aguilera
Assigned To: Mayuresh Nirhali
Fix For: 10.3.0.0
Attachments: A606Test.java, derby606-v2.diff, derby606-v3.diff,
derby606_impl-v4.diff, derby606_upgrade-v4.diff, derby606_v1.diff
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails with one of the following error
messages when applied to a very large table (2GB):
Log operation null encounters error writing itself out to the log stream,
this could be caused by an errant log operation or internal log buffer full
due to excessively large log operation. SQLSTATE: XJ001: Java exception: ':
java.io.IOException'.
or
The exception 'java.lang.ArrayIndexOutOfBoundsException' was thrown while
evaluating an expression. SQLSTATE: XJ001: Java exception: ':
[jira] Created: (DERBY-2103) After a Lexical Error due to syntax error , even a simple create table does not work on the same connection.
After a Lexical Error due to syntax error ,even a simple create table does not work on the same connection. - Key: DERBY-2103 URL: http://issues.apache.org/jira/browse/DERBY-2103 Project: Derby Issue Type: Bug Affects Versions: 10.3.0.0 Reporter: Suresh Thalamati Priority: Minor connect 'jdbc:derby:wombat;create=true'; create table t1(a int ) ; create table t2(a int ) ; -- this should fail. create table foo (a int , \YEAR\ int ) ; -- but this should not fail. But failing create table t4 ( b int ) ; FYI: $ java org.apache.derby.tools.ij ij version 10.3 ij run 'weird1.sql'; ij connect 'jdbc:derby:wombat;create=true'; ij create table t1(a int ) ; 0 rows inserted/updated/deleted ij create table t2(a int ) ; 0 rows inserted/updated/deleted ij -- this should fail. create table foo (a int , \YEAR\ int ) ; ERROR 42X02: Lexical error at line 2, column 28. Encountered: \\ (92), after : . ij -- but this should not fail. But failing create table t4 ( b int ) ; ERROR 42X01: Syntax error: Encountered at line 2, column 21. ij -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-606) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
[ http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12450263 ] Suresh Thalamati commented on DERBY-606: I agree with you , it might be trickey to check db versions especially on a readExpternal() call. It would be nice to avoid creating another class. Hopefully some one on the list some has ideas to do that. If you would like to proceed with a new class approach. It would be better to make the new class handle the old behavior . i.e create a new class CompressSpacePageOperation_V10_2 that extends theCompressSpacePageOperation and change the format id for the CompressSpacePageOperation class to a new one. This way it is easier to read the code, and remove the _v0 class later when upgrade is not supported from old version. Looks like assertion check is incorrect in the case you mentioned, please fix it. I would not call the assertion code under debug is in-consistent with insane-builds unless behaviour is different. In debug builds it is normal to do some extra checks , they are useful to get some information when stress tests fail after a few days run. actionCompressSpaceOperation() in LoggableAllocaction has RawTransaction as argument. It would be ok to expose the checkVersion method from logFactory to RawTransaction, Concrete implementation of RawTransaction abstract class , raw/xact/Xact.java already has the logFactory information. I would expect compress operation to work even if there are multiple alloc pages, .may be there is bug some where ; please file a JIRA. Thanks -suresh SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables Key: DERBY-606 URL: http://issues.apache.org/jira/browse/DERBY-606 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.1.0 Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition Reporter: Jeffrey Aguilera Assigned To: Mayuresh Nirhali Attachments: A606Test.java SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails with one of the following error messages when applied to a very large table (2GB): Log operation null encounters error writing itself out to the log stream, this could be caused by an errant log operation or internal log buffer full due to excessively large log operation. SQLSTATE: XJ001: Java exception: ': java.io.IOException'. or The exception 'java.lang.ArrayIndexOutOfBoundsException' was thrown while evaluating an expression. SQLSTATE: XJ001: Java exception: ': java.lang.ArrayIndexOutOfBoundsException'. In either case, no entry is written to the console log or to derby.log. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
[
http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12449848 ]
Suresh Thalamati commented on DERBY-801:
Hi Anders,
I agree with Knut, this issue can be marked as fixed, Thanks a lot for
working on this improvement.
-suresh
Allow parallel access to data files.
Key: DERBY-801
URL: http://issues.apache.org/jira/browse/DERBY-801
Project: Derby
Issue Type: Improvement
Components: Performance, Store
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
Environment: Any
Reporter: Øystein Grøvlen
Assigned To: Anders Morken
Fix For: 10.3.0.0
Attachments: DERBY-801-6.patch, DERBY-801-7.patch,
DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch,
DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
Derby currently serializes accesses to a data file. For example, the
implementation of RAFContainer.readPage is as follows:
synchronized (this) { // 'this' is a FileContainer, i.e. a file object
fileData.seek(pageOffset); // fileData is a RandomAccessFile
fileData.readFully(pageData, 0, pageSize);
}
I have experiemented with a patch where I have introduced several file
descriptors (RandomAccessFile objects) per RAFContainer. These are
used for reading. The principle is that when all readers are busy, a
readPage request will create a new reader. (There is a maximum number
of readers.) With this patch, throughput was improved by 50% on
linux. For more discussion on this, see
http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
The challenge with the suggested approach is to make a mechanism to
limit the number of open file descpriptors. Mike Matrigali has
suggested to use the existing CacheManager infrastructure for this
purpose. For a discussion on that, see:
http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-606) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
[ http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12449853 ] Suresh Thalamati commented on DERBY-606: Can this problem be soved by writing a different log records for this special case ? If the rest of system is working fine with the current assumption that negative numbers are not be written to the log. -suresh SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables Key: DERBY-606 URL: http://issues.apache.org/jira/browse/DERBY-606 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.1.0 Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition Reporter: Jeffrey Aguilera Assigned To: Mayuresh Nirhali Attachments: A606Test.java SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails with one of the following error messages when applied to a very large table (2GB): Log operation null encounters error writing itself out to the log stream, this could be caused by an errant log operation or internal log buffer full due to excessively large log operation. SQLSTATE: XJ001: Java exception: ': java.io.IOException'. or The exception 'java.lang.ArrayIndexOutOfBoundsException' was thrown while evaluating an expression. SQLSTATE: XJ001: Java exception: ': java.lang.ArrayIndexOutOfBoundsException'. In either case, no entry is written to the console log or to derby.log. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-378) support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,
[ http://issues.apache.org/jira/browse/DERBY-378?page=all ]
Suresh Thalamati reassigned DERBY-378:
--
Assignee: Suresh Thalamati
support for import/export of tables with clob/blob and the other binary
data types will be good addition to derby,
---
Key: DERBY-378
URL: http://issues.apache.org/jira/browse/DERBY-378
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.1.1.0
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Attachments: iexlobs.txt
Currently if I have a table that contains clob/blob column, import/export
operations on that table
throghs unsupported feature exception.
set schema iep;
set schema iep;
create table ntype(a int , ct CLOB(1024));
create table ntype1(bt BLOB(1024) , a int);
call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('iep', 'ntype' , 'extinout/ntype.dat' ,
null, null, null) ;
ERROR XIE0B: Column 'CT' in the table is of type CLOB, it is not supported by
th
e import/export feature.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2063) derbynet/ShutDownDBWhenNSShutsDownTest.junit fails with IBM JVM 142 and 15 on Linux platform
[ http://issues.apache.org/jira/browse/DERBY-2063?page=comments#action_12448330 ] Suresh Thalamati commented on DERBY-2063: - This test failure is not specific to Linux , it fails on other platforms(windows , SunOS) tooo . http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/testing/testlog/SunOS-5.10_i86pc-i386/472613-derbyall_diff.txt derbynet/ShutDownDBWhenNSShutsDownTest.junit fails with IBM JVM 142 and 15 on Linux platform Key: DERBY-2063 URL: http://issues.apache.org/jira/browse/DERBY-2063 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.2.1.8 Reporter: Manjula Kutty *** Start: ShutDownDBWhenNSShutsDownTest jdk1.5.0 DerbyNetClient derbynetmats:derbynetmats 2006-11-07 23:29:20 *** 0 add .F. There was 1 failure: 1) testEngineShutdownDoesNotTakeDownNS(org.apache.derbyTesting.functionTests.tests.derbynet.ShutDownDBWhenNSShutsDownTest)junit.framework.ComparisonFailure: Engine shutdown expected:XJ015 but was:08001 FAILURES!!! Tests run: 2, Failures: 1, Errors: 0 Test Failed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2049) Test jdbcapi/parameterMapping.java and lang/updatableResultSet.java are failing on J9 jvm ( J2ME Foundation Specification v1.0)
Test jdbcapi/parameterMapping.java and lang/updatableResultSet.java are failing on J9 jvm ( J2ME Foundation Specification v1.0) -- Key: DERBY-2049 URL: http://issues.apache.org/jira/browse/DERBY-2049 Project: Derby Issue Type: Test Affects Versions: 10.3.0.0 Environment: Java Version:J2ME Foundation Specification v1.0 Java Vendor: IBM Corporation Java home: c:\cloudtst\jartest\wctme5.7\ive Java classpath: c:/cloudtst/jartest/classes/derby.jar;c:/cloudtst/jartest/classes/derbyLocale_zh_TW.jar;c:/cloudtst/jartest/classes/derbyLocale_zh_CN.jar;c:/cloudtst/jartest/classes/derbyLocale_pt_BR.jar;c:/cloudtst/jartest/classes/derbyLocale_ko_KR.jar;c:/cloudtst/jartest/classes/derbyLocale_ja_JP.jar;c:/cloudtst/jartest/classes/derbyLocale_it.jar;c:/cloudtst/jartest/classes/derbyLocale_fr.jar;c:/cloudtst/jartest/classes/derbyLocale_es.jar;c:/cloudtst/jartest/classes/derbyLocale_de_DE.jar;c:/cloudtst/jartest/classes/derbytools.jar;c:/cloudtst/jartest/classes/derbynet.jar;c:/cloudtst/jartest/classes/derbyclient.jar;;c:/cloudtst/jartest/classes/derbyrun.jar;c:/cloudtst/jartest/classes/derbyTesting.jar;c:/cloudtst/jartest/classes/maps.jar;c:/cloudtst/jartest/classes/functionTests.jar;c:/cloudtst/jartest/classes/csext.jar;c:/cloudtst/jartest/tools/java/junit.jar;c:/cloudtst/jartest/tools/java/jndi/fscontext.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 2 Reporter: Suresh Thalamati *** Start: parameterMapping jdkJ2ME Foundation Specification v1.0 derbyall:jdbcapi 2006-11-04 06:38:30 *** 3003 del setTime() getTimestamp=xxFILTERED-TIMESTAMPxwas null false JDBC MATCH(OK) 3004 del setTime() as batch getTimestamp=xxFILTERED-TIMESTAMPxwas null false JDBC MATCH(OK) 3005 del setTime(null) getTimestamp=null was null true JDBC MATCH(OK) 3006 del setTime(null) as batch getTimestamp=null was null true JDBC MATCH(OK) 3006a3003,3006 setTime() (XCL12):An attempt was made to put a data value of type 'java.sql.Time' into a data value of type 'TIMESTAMP'. JDBC FAIL TIMESTAMP setTime() as batch (XCL12):An attempt was made to put a data value of type 'java.sql.Time' into a data value of type 'TIMESTAMP'. JDBC FAIL TIMESTAMP setTime(null) (XCL12):An attempt was made to put a data value of type 'java.sql.Time' into a data value of type 'TIMESTAMP'. JDBC FAIL TIMESTAMP setTime(null) as batch (XCL12):An attempt was made to put a data value of type 'java.sql.Time' into a data value of type 'TIMESTAMP'. JDBC FAIL TIMESTAMP 3055 del setObject(java.sql.Time) getTimestamp=xxFILTERED-TIMESTAMPxwas null false CLOUD EXT (OK) 3056 del setObject(java.sql.Time) as batch getTimestamp=xxFILTERED-TIMESTAMPxwas null false CLOUD EXT (OK) 3056a3055,3056 setObject(java.sql.Time) IC JDBC MATCH (INVALID) setObject(java.sql.Time) as batch IC JDBC MATCH (INVALID) Test Failed. *** End: parameterMapping jdkJ2ME Foundation Specification v1.0 derbyall:jdbcapi 2006-11-04 06:39:01 *** *** Start: updatableResultSet jdkJ2ME Foundation Specification v1.0 derbyall:derbylang 2006-11-04 05:50:02 *** 1828a1829 Got expected exception : An attempt was made to put a data value of type 'java.sql.Time' into a data value of type 'TIMESTAMP'. 1829a1831 Got expected exception : An attempt was made to put a data value of type 'java.sql.Time' into a data value of type 'TIMESTAMP'. 2508a2511 Got expected exception : An attempt was made to put a data value of type 'java.sql.Time' into a data value of type 'TIMESTAMP'. 2509a2513 Got expected exception : An attempt was made to put a data value of type 'java.sql.Time' into a data value of type 'TIMESTAMP'. Test Failed. *** End: updatableResultSet jdkJ2ME Foundation Specification v1.0 derbyall:derbylang 2006-11-04 05:50:44 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1240) creating /restoring a db from backup using createFrom with log at different location copies the log from backup to the db dir also.
[
http://issues.apache.org/jira/browse/DERBY-1240?page=comments#action_12443915 ]
Suresh Thalamati commented on DERBY-1240:
-
Fix for this problem is committed to trunk at revision 466221.
creating /restoring a db from backup using createFrom with log at different
location copies the log from backup to the db dir also.
---
Key: DERBY-1240
URL: http://issues.apache.org/jira/browse/DERBY-1240
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: WindowsXP/JDK142
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Priority: Minor
creating/restoring a database from a backup copy with exteral log location
copies the transaction log to the default location. db uses the external
location , but there is unnessary copy of transaction log at default
location.
connect 'wombat;create=true';
create table t1(a int );
insert into t1 values(15);
call SYSCS_UTIL.SYSCS_BACKUP_DATABASE('extinout/mybackup');
connect 'wombat;shutdown=true';
disconnect;
--- create a db from the backup using a different log location.
connect
'crwombat;createFrom=extinout/mybackup/wombat;logDevice=extinout/crwombatlog';
select * from t1;
--- If you loook under the crwombat dir you will find the log dir , it
should not be there because
-- transaction log is place st extinout/crwombatlog as specified in the
connection URL.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1981) copy routines in the FileUtil.java just return false on IO Exception. This leads to backup not reprting the real error in some cases.
copy routines in the FileUtil.java just return false on IO Exception. This leads to backup not reprting the real error in some cases. --- Key: DERBY-1981 URL: http://issues.apache.org/jira/browse/DERBY-1981 Project: Derby Issue Type: Improvement Components: Store Reporter: Suresh Thalamati Fix For: 10.3.0.0 Some of the copy routines in org.apache.derby.iapi.services.io;FileUtil.java , retuns false by catching IOExceptions. It will be better to throw exceptions. For example backup uses these routines in some case , if a copy during bacup fails becuase out of disk space ; all we tell the user is backup failed. It will be better to include the IO Excetpion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1925) Add re-encrytion of database test cases to the upgrade test..
[ http://issues.apache.org/jira/browse/DERBY-1925?page=all ] Suresh Thalamati resolved DERBY-1925. - Fix Version/s: 10.2.1.8 10.3.0.0 Resolution: Fixed Committed the test to 10.2 , on revision : r452682 . Merged the test from 10.2 to trunk(1.02) on revision : r466279 Add re-encrytion of database test cases to the upgrade test.. -- Key: DERBY-1925 URL: http://issues.apache.org/jira/browse/DERBY-1925 Project: Derby Issue Type: Test Affects Versions: 10.3.0.0, 10.2.2.0 Reporter: Suresh Thalamati Assigned To: Suresh Thalamati Fix For: 10.2.1.8, 10.3.0.0 Add a encryption of an un-encrypted database and re-encryption of encrypted database test case to the upgrade test. Please see DERBY-1156 for details about re-encryption feature. re-encrytpion test cases will be added to run only when test is executed using jar files. Upgrade test mixes the old version of derby classes in the jar files and the new classes when run under code-line using classes.; This cause boot time error when databases is encrypted ( This kind of mixing different version of classes is not supported , see DERBY-1898) . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12443000 ]
Suresh Thalamati commented on DERBY-1953:
-
Committed to trunk , revision 464970. Thanks Yip .
Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
-
Key: DERBY-1953
URL: http://issues.apache.org/jira/browse/DERBY-1953
Project: Derby
Issue Type: Improvement
Components: SQL
Affects Versions: 10.2.1.6
Environment: Any
Reporter: Yip Ng
Assigned To: Yip Ng
Priority: Minor
Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
derby1953-trunk-diff03.txt, derby1953-trunk-diff04.txt,
derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt,
derby1953-trunk-stat03.txt, derby1953-trunk-stat04.txt
According to SQL:2003 standard, section 11.39 trigger definition, under
Syntax Rules item 8:
If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
STATEMENT is implicit.
[ FOR EACH { ROW | STATEMENT } ]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12442683 ]
Suresh Thalamati commented on DERBY-1953:
-
Hi Yip ,
Thanks for enhancing the patch , withe Bernt's suggestion. I am not able to
apply the patch cleanly, the changes in this patch are conflicting with some
other changes (most probably u'r derby-630 fix). Could you please resolve
the conflicts and post the patch again.
if there are no further comments from any one else. I will commit the patch.
Thanks
-suresh
Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
-
Key: DERBY-1953
URL: http://issues.apache.org/jira/browse/DERBY-1953
Project: Derby
Issue Type: Improvement
Components: SQL
Affects Versions: 10.2.1.6
Environment: Any
Reporter: Yip Ng
Assigned To: Yip Ng
Priority: Minor
Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
derby1953-trunk-diff03.txt, derby1953-trunk-stat01.txt,
derby1953-trunk-stat02.txt, derby1953-trunk-stat03.txt
According to SQL:2003 standard, section 11.39 trigger definition, under
Syntax Rules item 8:
If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
STATEMENT is implicit.
[ FOR EACH { ROW | STATEMENT } ]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12441312 ]
Suresh Thalamati commented on DERBY-1953:
-
I reviewed the latest patch , it looks good. I will commit it, after running
the tests.
Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
-
Key: DERBY-1953
URL: http://issues.apache.org/jira/browse/DERBY-1953
Project: Derby
Issue Type: Improvement
Components: SQL
Affects Versions: 10.2.1.6
Environment: Any
Reporter: Yip Ng
Assigned To: Yip Ng
Priority: Minor
Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
According to SQL:2003 standard, section 11.39 trigger definition, under
Syntax Rules item 8:
If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
STATEMENT is implicit.
[ FOR EACH { ROW | STATEMENT } ]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1819) couple of small errors in the admin guide documentation of NetworkServerControl() API (shutdown and sysinfo ...)
[ http://issues.apache.org/jira/browse/DERBY-1819?page=comments#action_12440575 ] Suresh Thalamati commented on DERBY-1819: - Thanks for working on this issue , Laura. Changes looks good to me, patch can be committted. +1. /suresh couple of small errors in the admin guide documentation of NetworkServerControl() API (shutdown and sysinfo ...) -- Key: DERBY-1819 URL: http://issues.apache.org/jira/browse/DERBY-1819 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6 Reporter: Suresh Thalamati Assigned To: Laura Stewart Priority: Trivial Fix For: 10.2.2.0 Attachments: derby1819_1.diff, derby1819_html1.zip 1) in Shutting down by using the API(http://db.apache.org/derby/docs/dev/adminguide/tadminconfig815357.html) I think the ollowing senetence is not correct in this section. There is an example later in the section , that shows t how to shutdown the network server. For example: shutdown(); Above can be removed. or change the description that refelect that it is the metod name to shutdown the database. 2) Obtaining system information by using the API (http://db.apache.org/derby/docs/dev/adminguide/tadminconfig815853.html) Following sentence , I think refers to only the getSysinfo() method These methods return information about the Network Server running on the current machine on the default port number (1527). These methods should be replaced by this method 3)In Obtaining Network Server properties by using the getCurrent Properties method (http://db.apache.org/derby/docs/dev/adminguide/tadminconfig815822.html) section : It returns a Properties object with the value of all the NetServer properties in the above sentence NetServer is incorrect , it should be Network Server -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1240) creating /restoring a db from backup using createFrom with log at different location copies the log from backup to the db dir also.
[ http://issues.apache.org/jira/browse/DERBY-1240?page=all ]
Suresh Thalamati reassigned DERBY-1240:
---
Assignee: Suresh Thalamati
creating /restoring a db from backup using createFrom with log at different
location copies the log from backup to the db dir also.
---
Key: DERBY-1240
URL: http://issues.apache.org/jira/browse/DERBY-1240
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.2.1.6, 10.1.3.0
Environment: WindowsXP/JDK142
Reporter: Suresh Thalamati
Assigned To: Suresh Thalamati
Priority: Minor
creating/restoring a database from a backup copy with exteral log location
copies the transaction log to the default location. db uses the external
location , but there is unnessary copy of transaction log at default
location.
connect 'wombat;create=true';
create table t1(a int );
insert into t1 values(15);
call SYSCS_UTIL.SYSCS_BACKUP_DATABASE('extinout/mybackup');
connect 'wombat;shutdown=true';
disconnect;
--- create a db from the backup using a different log location.
connect
'crwombat;createFrom=extinout/mybackup/wombat;logDevice=extinout/crwombatlog';
select * from t1;
--- If you loook under the crwombat dir you will find the log dir , it
should not be there because
-- transaction log is place st extinout/crwombatlog as specified in the
connection URL.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1925) Add re-encrytion of database test cases to the upgrade test..
Add re-encrytion of database test cases to the upgrade test.. - Key: DERBY-1925 URL: http://issues.apache.org/jira/browse/DERBY-1925 Project: Derby Issue Type: Test Affects Versions: 10.2.2.0, 10.3.0.0 Reporter: Suresh Thalamati Assigned To: Suresh Thalamati Add a encryption of an un-encrypted database and re-encryption of encrypted database test case to the upgrade test. Please see DERBY-1156 for details about re-encryption feature. re-encrytpion test cases will be added to run only when test is executed using jar files. Upgrade test mixes the old version of derby classes in the jar files and the new classes when run under code-line using classes.; This cause boot time error when databases is encrypted ( This kind of mixing different version of classes is not supported , see DERBY-1898) . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1898) can not boot derby if class path contains 10.1 jars first and then 10.2 jars
[ http://issues.apache.org/jira/browse/DERBY-1898?page=all ] Suresh Thalamati resolved DERBY-1898. - Resolution: Invalid Derby is not expected to work correctly, if two versions of derby jar files are present in the classpath. can not boot derby if class path contains 10.1 jars first and then 10.2 jars -- Key: DERBY-1898 URL: http://issues.apache.org/jira/browse/DERBY-1898 Project: Derby Issue Type: Bug Affects Versions: 10.2.1.6, 10.2.2.0 Environment: $ echo $CLASSPATH c:/suresht/jars_10_1//derby.jar;c:/suresht/jars_10_1//derbytools.jar;c:/suresht/ jars_10_1//derbyclient.jar;c:/suresht/jars_10_1//derbynet.jar;c:/suresht/jars_10 _1//derbyTesting.jar;c:/suresht/jars_10_1//jakarta-oro-2.0.8.jar;c:/suresht/jars _10_1//derbyLocale_de_DE.jar;c:/suresht/jars_10_1//derbyLocale_es.jar;c:/suresht /jars_10_1//derbyLocale_fr.jar;c:/suresht/jars_10_1//derbyLocale_it.jar;c:/sures ht/jars_10_1//derbyLocale_ja_JP.jar;c:/suresht/jars_10_1//derbyLocale_ko_KR.jar; c:/suresht/jars_10_1//derbyLocale_pt_BR.jar;c:/suresht/jars_10_1//derbyLocale_zh _CN.jar;c:/suresht/jars_10_1//derbyLocale_zh_TW.jar;c:/suresht/jars_10_1//junit. jar;C:/suresht/jars_10_2/derby.jar $ Reporter: Suresh Thalamati Fix For: 10.2.2.0 java -Dij.exceptionTrace=true -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij Exception in thread main java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.derby.impl.tools.ij.util.loadDriver(Unknown Source) at org.apache.derby.impl.tools.ij.util.loadDriverIfKnown(Unknown Source) at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source) at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source) at org.apache.derby.impl.tools.ij.ConnectionEnv.init(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.init(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain14.init(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.getutilMain(Unknown Source) at org.apache.derby.impl.tools.ij.Main.init(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.init(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.getMain(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) Caused by: java.lang.SecurityException: sealing violation: package org.apache.de rby.iapi.services.crypto is sealed at java.net.URLClassLoader.defineClass(URLClassLoader.java:226) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.derby.impl.services.monitor.BaseMonitor.getImplementations (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.getDefaultImplemen tations(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unkno wn Source) at org.apache.derby.impl.services.monitor.FileMonitor.init(Unknown Sou rce) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown S ource) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.clinit(Unknown Source) ... 16 more $ I think the problem is in 10.2 ,, cryptograph modules entries were updated with a new factory. the new one is : derby.module.cryptographyJ2=org.apache.derby.impl.services.jce.JCECipherFactoryBuilder and the old one in 10.1 was derby.module.cryptographyJ2=org.apache.derby.impl.services.jce.JCECipherFactory -- My understanding was only one modules.properties get loaded. So updating the above property should not cause any issues. But that assuption seems to be wrong , for some reason , monitor grabs all the modules.properties and loads them. I just have no clue , why we do that ? (any one know why we do that ? ) . I this
[jira] Commented: (DERBY-1898) can not boot derby if class path contains 10.1 jars first and then 10.2 jars
[ http://issues.apache.org/jira/browse/DERBY-1898?page=comments#action_12438594 ] Suresh Thalamati commented on DERBY-1898: - But fixing the above one won't solve the existing problem with old jars, I think the fix for this issues is to use the different name for the crypto module. Above idea to address the problem using new key name for crypto module will not work. Even if a new key is used for crypto module , we will be still attempting to load the new class from the sealed 10.2 jar and fail. can not boot derby if class path contains 10.1 jars first and then 10.2 jars -- Key: DERBY-1898 URL: http://issues.apache.org/jira/browse/DERBY-1898 Project: Derby Issue Type: Bug Affects Versions: 10.2.1.5, 10.2.2.0 Environment: $ echo $CLASSPATH c:/suresht/jars_10_1//derby.jar;c:/suresht/jars_10_1//derbytools.jar;c:/suresht/ jars_10_1//derbyclient.jar;c:/suresht/jars_10_1//derbynet.jar;c:/suresht/jars_10 _1//derbyTesting.jar;c:/suresht/jars_10_1//jakarta-oro-2.0.8.jar;c:/suresht/jars _10_1//derbyLocale_de_DE.jar;c:/suresht/jars_10_1//derbyLocale_es.jar;c:/suresht /jars_10_1//derbyLocale_fr.jar;c:/suresht/jars_10_1//derbyLocale_it.jar;c:/sures ht/jars_10_1//derbyLocale_ja_JP.jar;c:/suresht/jars_10_1//derbyLocale_ko_KR.jar; c:/suresht/jars_10_1//derbyLocale_pt_BR.jar;c:/suresht/jars_10_1//derbyLocale_zh _CN.jar;c:/suresht/jars_10_1//derbyLocale_zh_TW.jar;c:/suresht/jars_10_1//junit. jar;C:/suresht/jars_10_2/derby.jar $ Reporter: Suresh Thalamati Fix For: 10.2.1.5, 10.2.2.0 java -Dij.exceptionTrace=true -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij Exception in thread main java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.derby.impl.tools.ij.util.loadDriver(Unknown Source) at org.apache.derby.impl.tools.ij.util.loadDriverIfKnown(Unknown Source) at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source) at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source) at org.apache.derby.impl.tools.ij.ConnectionEnv.init(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.init(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain14.init(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.getutilMain(Unknown Source) at org.apache.derby.impl.tools.ij.Main.init(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.init(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.getMain(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) Caused by: java.lang.SecurityException: sealing violation: package org.apache.de rby.iapi.services.crypto is sealed at java.net.URLClassLoader.defineClass(URLClassLoader.java:226) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.derby.impl.services.monitor.BaseMonitor.getImplementations (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.getDefaultImplemen tations(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unkno wn Source) at org.apache.derby.impl.services.monitor.FileMonitor.init(Unknown Sou rce) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown S ource) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.clinit(Unknown Source) ... 16 more $ I think the problem is in 10.2 ,, cryptograph modules entries were updated with a new factory. the new one is : derby.module.cryptographyJ2=org.apache.derby.impl.services.jce.JCECipherFactoryBuilder and the old one in 10.1 was derby.module.cryptographyJ2=org.apache.derby.impl.services.jce.JCECipherFactory -- My understanding was only one
[jira] Resolved: (DERBY-1854) SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a primary key and a foreign key
[ http://issues.apache.org/jira/browse/DERBY-1854?page=all ]
Suresh Thalamati resolved DERBY-1854.
-
Resolution: Fixed
committed to 10.2 as part of meg-merge , revision. 449013.
SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a
primary key and a foreign key
--
Key: DERBY-1854
URL: http://issues.apache.org/jira/browse/DERBY-1854
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.3.0, 10.1.3.1
Environment: Reproduced on Linux, Win2k, and WinXP running JDK 1.4.2.x
Reporter: Chad Loder
Assigned To: Suresh Thalamati
Priority: Critical
Fix For: 10.2.1.0, 10.3.0.0
Attachments: derby-1854-andrew-10.1.diff, derby-1854.diff,
derby-1854_v1.diff
Running the following short SQL script from ij will cause an error ERROR
XSAI2: The conglomerate (817) requested does not exist.. It appears that
the SYSCS_COMPRESS_TABLE function corrupts tables that have a single column
which is both a primary key and a foreign key.
connect 'jdbc:derby:/testdb;create=true';
CREATE TABLE users (
user_id INT NOT NULL GENERATED BY DEFAULT AS IDENTITY,
user_login VARCHAR(255) NOT NULL,
PRIMARY KEY (user_id));
CREATE TABLE admins (
user_id INT NOT NULL,
PRIMARY KEY (user_id),
CONSTRAINT admin_uid_fk FOREIGN KEY (user_id) REFERENCES users (user_id));
INSERT INTO users (user_login) VALUES('TEST1');
INSERT INTO admins VALUES (VALUES IDENTITY_VAL_LOCAL());
CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'ADMINS', 0);
SELECT * from admins;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1641) Conglomerate requested does not exist after syscs_import_table with FK
[ http://issues.apache.org/jira/browse/DERBY-1641?page=all ] Suresh Thalamati resolved DERBY-1641. - Fix Version/s: 10.3.0.0 Resolution: Fixed This is a duplicate of DERBY-1854 . Fixed in 10.2 , revision 449013 and in 10.3. revision 448758. Conglomerate requested does not exist after syscs_import_table with FK -- Key: DERBY-1641 URL: http://issues.apache.org/jira/browse/DERBY-1641 Project: Derby Issue Type: Bug Components: SQL, Store Affects Versions: 10.1.3.1 Environment: Java 1.5.0_06-b05 Linux (CentOS 4) Reporter: Matt Frantz Priority: Critical Fix For: 10.2.2.0, 10.3.0.0 I have a repeatable sequence that always causes the Conglomerate (X) requested does not exist error on my system. There are several steps. You can use ij as follows: 1. Start with a new database, e.g. connect 'jdbc:derby:test;create=true'; 2. create table y( pk integer primary key ); 3. insert into y values (123); 4. create table z( pk integer not null primary key references y ); 5. Create a file containing a single row of ASCII data with the number 123 (in ASCII) in it. e.g. /tmp/z 6. call syscs_util.syscs_import_table( null, 'Z', '/tmp/z', ',', , null, 1 ); 7. Try to access the Z table, e.g. SELECT * FROM z; or DROP TABLE z; At this point, I always get the error. I can use this sequence in other contexts, but the difference, as far as I can tell, is that the table Z has a column that is both PK and FK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1854) SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a primary key and a foreign key
[ http://issues.apache.org/jira/browse/DERBY-1854?page=all ]
Suresh Thalamati updated DERBY-1854:
Attachment: derby-1854.diff
Problem was all the conglomerate descriptor entries in sys.sysconglomerates
were not getting updated with new conglomerate number generated for an index
during compress/bulk-insert, when an index is shared. Update code was assuming
conglomerate id is common when an index is shared, but that is not correct.
ConglomerateID's in sys.sysconglomerates are unique.
This patch modifies the update conglomerate descriptor code to update each
conglomerate descriptor separately using conglomerateID as the key, when
there are more than one conglomerate descriptor referring to the same
conglomerate(conglomerate number).
It would be great, if some can review the attached patch.
svn stat:
M java\engine\org\apache\derby\impl\sql\catalog\DataDictionaryImpl.java
M
java\testing\org\apache\derbyTesting\functionTests\tests\lang\compressTable.sql
M
java\testing\org\apache\derbyTesting\functionTests\master\compressTable.out
SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a
primary key and a foreign key
--
Key: DERBY-1854
URL: http://issues.apache.org/jira/browse/DERBY-1854
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.3.0, 10.1.3.1
Environment: Reproduced on Linux, Win2k, and WinXP running JDK 1.4.2.x
Reporter: Chad Loder
Assigned To: Suresh Thalamati
Priority: Critical
Fix For: 10.2.2.0
Attachments: derby-1854.diff
Running the following short SQL script from ij will cause an error ERROR
XSAI2: The conglomerate (817) requested does not exist.. It appears that
the SYSCS_COMPRESS_TABLE function corrupts tables that have a single column
which is both a primary key and a foreign key.
connect 'jdbc:derby:/testdb;create=true';
CREATE TABLE users (
user_id INT NOT NULL GENERATED BY DEFAULT AS IDENTITY,
user_login VARCHAR(255) NOT NULL,
PRIMARY KEY (user_id));
CREATE TABLE admins (
user_id INT NOT NULL,
PRIMARY KEY (user_id),
CONSTRAINT admin_uid_fk FOREIGN KEY (user_id) REFERENCES users (user_id));
INSERT INTO users (user_login) VALUES('TEST1');
INSERT INTO admins VALUES (VALUES IDENTITY_VAL_LOCAL());
CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'ADMINS', 0);
SELECT * from admins;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1854) SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a primary key and a foreign key
[ http://issues.apache.org/jira/browse/DERBY-1854?page=all ]
Suresh Thalamati updated DERBY-1854:
Attachment: derby-1854_v1.diff
This patch has same fix as in deryby-1854.diff , Only thing new in this
patch is the updates to the importExportThruIJ.sql to test import nto a
table that has same column as a primary key and a foreign key (ADMINS table)..
import internally uses bulk-insert when the table is empty , it also drops
and recreates the indexes, sys,sysconglomerates were not gettting updated
correctly in this case also because , bul-insert calls the same update
conglomerate descriptors method in the data dictionary.
SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a
primary key and a foreign key
--
Key: DERBY-1854
URL: http://issues.apache.org/jira/browse/DERBY-1854
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.3.0, 10.1.3.1
Environment: Reproduced on Linux, Win2k, and WinXP running JDK 1.4.2.x
Reporter: Chad Loder
Assigned To: Suresh Thalamati
Priority: Critical
Fix For: 10.2.1.0, 10.3.0.0
Attachments: derby-1854-andrew-10.1.diff, derby-1854.diff,
derby-1854_v1.diff
Running the following short SQL script from ij will cause an error ERROR
XSAI2: The conglomerate (817) requested does not exist.. It appears that
the SYSCS_COMPRESS_TABLE function corrupts tables that have a single column
which is both a primary key and a foreign key.
connect 'jdbc:derby:/testdb;create=true';
CREATE TABLE users (
user_id INT NOT NULL GENERATED BY DEFAULT AS IDENTITY,
user_login VARCHAR(255) NOT NULL,
PRIMARY KEY (user_id));
CREATE TABLE admins (
user_id INT NOT NULL,
PRIMARY KEY (user_id),
CONSTRAINT admin_uid_fk FOREIGN KEY (user_id) REFERENCES users (user_id));
INSERT INTO users (user_login) VALUES('TEST1');
INSERT INTO admins VALUES (VALUES IDENTITY_VAL_LOCAL());
CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'ADMINS', 0);
SELECT * from admins;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1854) SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a primary key and a foreign key
[
http://issues.apache.org/jira/browse/DERBY-1854?page=comments#action_12436704 ]
Suresh Thalamati commented on DERBY-1854:
-
Committed to trunk on revision 448758. Thanks for taking time to review the
patch , Andrew, Mamta.
SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a
primary key and a foreign key
--
Key: DERBY-1854
URL: http://issues.apache.org/jira/browse/DERBY-1854
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.3.0, 10.1.3.1
Environment: Reproduced on Linux, Win2k, and WinXP running JDK 1.4.2.x
Reporter: Chad Loder
Assigned To: Suresh Thalamati
Priority: Critical
Fix For: 10.2.1.0, 10.3.0.0
Attachments: derby-1854-andrew-10.1.diff, derby-1854.diff,
derby-1854_v1.diff
Running the following short SQL script from ij will cause an error ERROR
XSAI2: The conglomerate (817) requested does not exist.. It appears that
the SYSCS_COMPRESS_TABLE function corrupts tables that have a single column
which is both a primary key and a foreign key.
connect 'jdbc:derby:/testdb;create=true';
CREATE TABLE users (
user_id INT NOT NULL GENERATED BY DEFAULT AS IDENTITY,
user_login VARCHAR(255) NOT NULL,
PRIMARY KEY (user_id));
CREATE TABLE admins (
user_id INT NOT NULL,
PRIMARY KEY (user_id),
CONSTRAINT admin_uid_fk FOREIGN KEY (user_id) REFERENCES users (user_id));
INSERT INTO users (user_login) VALUES('TEST1');
INSERT INTO admins VALUES (VALUES IDENTITY_VAL_LOCAL());
CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'ADMINS', 0);
SELECT * from admins;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1718) creating an after insert trigger with trigger action involving xml datatype throws java.io.NottSerializableException
[ http://issues.apache.org/jira/browse/DERBY-1718?page=comments#action_12436121 ] Suresh Thalamati commented on DERBY-1718: - Committed to trunk on revision 448085.. creating an after insert trigger with trigger action involving xml datatype throws java.io.NottSerializableException -- Key: DERBY-1718 URL: http://issues.apache.org/jira/browse/DERBY-1718 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0, 10.2.2.0 Environment: Java Version:1.4.2 Java Vendor: IBM Corporation Reporter: Suresh Thalamati Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1718-trunk-diff01.txt, derby1718-trunk-diff02.txt, derby1718-trunk-stat01.txt, derby1718-trunk-stat02.txt, stk.txt creating an after insert trigger with trigger action involving xml datatype throws following error : ij create trigger trigxml after insert on t1 for each statement mode db2sql insert into t2 values (1, xmlparse(document 'name ram /name' preserve whitespace)); ERROR XSDAJ: Exception during write of a serializable or SQLData object ERROR XJ001: Java exception: 'org.apache.derby.iapi.types.SqlXmlUtil: java.io.No ton'.SerializableExcepti ij repro: connect 'jdbc:derby:wombat;create=true'; create table t1 (i int, x xml); create table t2 (i int, x xml); insert into t2 values (1, xmlparse(document 'name suresh /name' preserve whitespace)); --- following trigger creation is failing ,. create trigger trigxml after insert on t1 for each statement mode db2sql insert into t2 values (1, xmlparse(document 'name ram /name' preserve whitespace)); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1854) SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a primary key and a foreign key
[
http://issues.apache.org/jira/browse/DERBY-1854?page=comments#action_12436361 ]
Suresh Thalamati commented on DERBY-1854:
-
debugged this bug little bit , looks like the problem is one of the
conglomerate descriptor entries in the sys.sysconglomerates are not getting
updated with the new conglomerate number that got created as part of the
compress . In the test case , it happens to be entry for the foreign key
index.
The current code that updates the conglomerate numbers indexes assumes ,there
are duplicate entries in the sys.sysconglomerate with same conglomerid
entries , when multiple indexes are referring to a conglomerate. I think
this assumption is not true any more , fix for DERBY-655 ensures
conglomerid is unique in sys.sysconglomerates.
This bug is likely to show up in all branches , where the fix for DERBY-655
is checked in.
/suresh
SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a
primary key and a foreign key
--
Key: DERBY-1854
URL: http://issues.apache.org/jira/browse/DERBY-1854
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.3.1, 10.1.3.0
Environment: Reproduced on Linux, Win2k, and WinXP running JDK 1.4.2.x
Reporter: Chad Loder
Priority: Critical
Fix For: 10.2.2.0
Running the following short SQL script from ij will cause an error ERROR
XSAI2: The conglomerate (817) requested does not exist.. It appears that
the SYSCS_COMPRESS_TABLE function corrupts tables that have a single column
which is both a primary key and a foreign key.
connect 'jdbc:derby:/testdb;create=true';
CREATE TABLE users (
user_id INT NOT NULL GENERATED BY DEFAULT AS IDENTITY,
user_login VARCHAR(255) NOT NULL,
PRIMARY KEY (user_id));
CREATE TABLE admins (
user_id INT NOT NULL,
PRIMARY KEY (user_id),
CONSTRAINT admin_uid_fk FOREIGN KEY (user_id) REFERENCES users (user_id));
INSERT INTO users (user_login) VALUES('TEST1');
INSERT INTO admins VALUES (VALUES IDENTITY_VAL_LOCAL());
CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'ADMINS', 0);
SELECT * from admins;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1854) SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a primary key and a foreign key
[ http://issues.apache.org/jira/browse/DERBY-1854?page=all ]
Suresh Thalamati reassigned DERBY-1854:
---
Assignee: Suresh Thalamati
SYSCS_COMPRESS_TABLE corrupts table with a single column which is both a
primary key and a foreign key
--
Key: DERBY-1854
URL: http://issues.apache.org/jira/browse/DERBY-1854
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.3.1, 10.1.3.0
Environment: Reproduced on Linux, Win2k, and WinXP running JDK 1.4.2.x
Reporter: Chad Loder
Assigned To: Suresh Thalamati
Priority: Critical
Fix For: 10.2.2.0
Running the following short SQL script from ij will cause an error ERROR
XSAI2: The conglomerate (817) requested does not exist.. It appears that
the SYSCS_COMPRESS_TABLE function corrupts tables that have a single column
which is both a primary key and a foreign key.
connect 'jdbc:derby:/testdb;create=true';
CREATE TABLE users (
user_id INT NOT NULL GENERATED BY DEFAULT AS IDENTITY,
user_login VARCHAR(255) NOT NULL,
PRIMARY KEY (user_id));
CREATE TABLE admins (
user_id INT NOT NULL,
PRIMARY KEY (user_id),
CONSTRAINT admin_uid_fk FOREIGN KEY (user_id) REFERENCES users (user_id));
INSERT INTO users (user_login) VALUES('TEST1');
INSERT INTO admins VALUES (VALUES IDENTITY_VAL_LOCAL());
CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'ADMINS', 0);
SELECT * from admins;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1838) Derby allows dual boot which can cause corruption of databases with JVM's lower than 1.4.2 on non-windows systems
[ http://issues.apache.org/jira/browse/DERBY-1838?page=comments#action_12435968 ] Suresh Thalamati commented on DERBY-1838: - you are right John. Dual boot through multiple JVMs is prevented on Unix from JDK1.4 (1.4.0) using the file lock support., provided in jdk1.4. /suresh Derby allows dual boot which can cause corruption of databases with JVM's lower than 1.4.2 on non-windows systems -- Key: DERBY-1838 URL: http://issues.apache.org/jira/browse/DERBY-1838 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.1.0, 10.1.2.1, 10.1.3.0, 10.3.0.0, 10.1.4.0, 10.1.3.1, 10.1.3.2, 10.2.2.0 Reporter: Kathey Marsden Priority: Critical On non-windows systems accidental access of a database from two JVM's is not prevented on JVM's lower than 1.4.2. The issue can be triggered by a common user error, for example accessing a database from two ij sessions. This can cause unrecoverable corruption. It is critical that users upgrade to 1.4.2 if there is a possibility that a user might access Derby in this way. There was no known way to fix this issue until 1.4.2, so it is not likely that it can be resolved within Derby. Upgrade of the JVM is the only known solution now. Note: Even with 1.4.2 the dual boot issue exists in certain scenarios which are not well documented. DERBY-700 has been filed and hopefully other fatal usage cases that can lead to dual boot can be isolated and resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1718) creating an after insert trigger with trigger action involving xml datatype throws java.io.NottSerializableException
[ http://issues.apache.org/jira/browse/DERBY-1718?page=comments#action_12436061 ] Suresh Thalamati commented on DERBY-1718: - I did a quick review of this patch. One change that caught my attention is the new format id added in this patch , I am wondering if this will cause any upgrade issues, if some one does soft-upgrade to 10.2, creates the trigger and then reverts back to 10.1 I think it should not cause any problems during recovery, because it is written as part of another higher level object (Storable Prepared Statement). Any one know if the new format id will cause any errors when building the stored prepared statement descriptors list or when the trigger gets executed on 10.1 ? Thanks -suresh creating an after insert trigger with trigger action involving xml datatype throws java.io.NottSerializableException -- Key: DERBY-1718 URL: http://issues.apache.org/jira/browse/DERBY-1718 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0, 10.2.2.0 Environment: Java Version:1.4.2 Java Vendor: IBM Corporation Reporter: Suresh Thalamati Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1718-trunk-diff01.txt, derby1718-trunk-diff02.txt, derby1718-trunk-stat01.txt, derby1718-trunk-stat02.txt, stk.txt creating an after insert trigger with trigger action involving xml datatype throws following error : ij create trigger trigxml after insert on t1 for each statement mode db2sql insert into t2 values (1, xmlparse(document 'name ram /name' preserve whitespace)); ERROR XSDAJ: Exception during write of a serializable or SQLData object ERROR XJ001: Java exception: 'org.apache.derby.iapi.types.SqlXmlUtil: java.io.No ton'.SerializableExcepti ij repro: connect 'jdbc:derby:wombat;create=true'; create table t1 (i int, x xml); create table t2 (i int, x xml); insert into t2 values (1, xmlparse(document 'name suresh /name' preserve whitespace)); --- following trigger creation is failing ,. create trigger trigxml after insert on t1 for each statement mode db2sql insert into t2 values (1, xmlparse(document 'name ram /name' preserve whitespace)); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1786) a crash during re-encryption of an existing database with lot of tables can make database unrecoverable on a next boot.
[ http://issues.apache.org/jira/browse/DERBY-1786?page=all ] Suresh Thalamati updated DERBY-1786: Component/s: Store Fix Version/s: 10.2.1.0 10.3.0.0 committed to 10.2 as part of meg-merge done by Rick. on revision 446700. a crash during re-encryption of an existing database with lot of tables can make database unrecoverable on a next boot. - Key: DERBY-1786 URL: http://issues.apache.org/jira/browse/DERBY-1786 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.2.1.0, 10.3.0.0 Reporter: Suresh Thalamati Assigned To: Suresh Thalamati Fix For: 10.2.1.0, 10.3.0.0 Attachments: derby-1786.diff, stk.txt While running reencryt crash/recovery functional test with 1000 tables (2000 containers) , I hit a following boot failire. ERROR XJ040: Failed to start database 'wombat_pwd_en', see the next exception fo r details. ERROR XSTB0: An exception was thrown during transaction abort. java.sql.SQLException: Failed to start database 'wombat_pwd_en', see the next ex = begin nested exception, level (1) === ERROR XSRS4: Error renaming file (during backup) from E:\suresht\adhoctests\reencryption\dbs\wombat_pwd_en\seg0\c340.dat to E:\suresht\adhoctests\reencryption\dbs\wombat_pwd_en\seg0\n340.dat. --- After bit of debugging ; my suspicion is this problem is happening becuase of more than one log file switch during re-encryption and current re-encryption recovery code does not seem to handle it correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1786) a crash during re-encryption of an existing database with lot of tables can make database unrecoverable on a next boot.
[ http://issues.apache.org/jira/browse/DERBY-1786?page=all ] Suresh Thalamati resolved DERBY-1786. - Resolution: Fixed a crash during re-encryption of an existing database with lot of tables can make database unrecoverable on a next boot. - Key: DERBY-1786 URL: http://issues.apache.org/jira/browse/DERBY-1786 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.2.1.0, 10.3.0.0 Reporter: Suresh Thalamati Assigned To: Suresh Thalamati Fix For: 10.2.1.0, 10.3.0.0 Attachments: derby-1786.diff, stk.txt While running reencryt crash/recovery functional test with 1000 tables (2000 containers) , I hit a following boot failire. ERROR XJ040: Failed to start database 'wombat_pwd_en', see the next exception fo r details. ERROR XSTB0: An exception was thrown during transaction abort. java.sql.SQLException: Failed to start database 'wombat_pwd_en', see the next ex = begin nested exception, level (1) === ERROR XSRS4: Error renaming file (during backup) from E:\suresht\adhoctests\reencryption\dbs\wombat_pwd_en\seg0\c340.dat to E:\suresht\adhoctests\reencryption\dbs\wombat_pwd_en\seg0\n340.dat. --- After bit of debugging ; my suspicion is this problem is happening becuase of more than one log file switch during re-encryption and current re-encryption recovery code does not seem to handle it correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
[
http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12435610 ]
Suresh Thalamati commented on DERBY-801:
Hi Knut ,
Patch is good. It is ok with me , if you would like to commit the current
patch and let Anders address, other enhancements in the followup patches.
Thanks
-suersh
Allow parallel access to data files.
Key: DERBY-801
URL: http://issues.apache.org/jira/browse/DERBY-801
Project: Derby
Issue Type: Improvement
Components: Performance, Store
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2,
10.1.2.0, 10.1.2.1
Environment: Any
Reporter: Øystein Grøvlen
Assigned To: Anders Morken
Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch,
DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
Derby currently serializes accesses to a data file. For example, the
implementation of RAFContainer.readPage is as follows:
synchronized (this) { // 'this' is a FileContainer, i.e. a file object
fileData.seek(pageOffset); // fileData is a RandomAccessFile
fileData.readFully(pageData, 0, pageSize);
}
I have experiemented with a patch where I have introduced several file
descriptors (RandomAccessFile objects) per RAFContainer. These are
used for reading. The principle is that when all readers are busy, a
readPage request will create a new reader. (There is a maximum number
of readers.) With this patch, throughput was improved by 50% on
linux. For more discussion on this, see
http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
The challenge with the suggested approach is to make a mechanism to
limit the number of open file descpriptors. Mike Matrigali has
suggested to use the existing CacheManager infrastructure for this
purpose. For a discussion on that, see:
http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1718) creating an after insert trigger with trigger action involving xml datatype throws java.io.NottSerializableException
[ http://issues.apache.org/jira/browse/DERBY-1718?page=comments#action_12435616 ] Suresh Thalamati commented on DERBY-1718: - Thanks for working on this issue Yip. I will run derbyall and commit the patch. Thanks a lot for taking time to review the patch , Army. /suresh creating an after insert trigger with trigger action involving xml datatype throws java.io.NottSerializableException -- Key: DERBY-1718 URL: http://issues.apache.org/jira/browse/DERBY-1718 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0, 10.2.2.0 Environment: Java Version:1.4.2 Java Vendor: IBM Corporation Reporter: Suresh Thalamati Assigned To: Yip Ng Fix For: 10.2.1.0 Attachments: derby1718-trunk-diff01.txt, derby1718-trunk-diff02.txt, derby1718-trunk-stat01.txt, derby1718-trunk-stat02.txt, stk.txt creating an after insert trigger with trigger action involving xml datatype throws following error : ij create trigger trigxml after insert on t1 for each statement mode db2sql insert into t2 values (1, xmlparse(document 'name ram /name' preserve whitespace)); ERROR XSDAJ: Exception during write of a serializable or SQLData object ERROR XJ001: Java exception: 'org.apache.derby.iapi.types.SqlXmlUtil: java.io.No ton'.SerializableExcepti ij repro: connect 'jdbc:derby:wombat;create=true'; create table t1 (i int, x xml); create table t2 (i int, x xml); insert into t2 values (1, xmlparse(document 'name suresh /name' preserve whitespace)); --- following trigger creation is failing ,. create trigger trigxml after insert on t1 for each statement mode db2sql insert into t2 values (1, xmlparse(document 'name ram /name' preserve whitespace)); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1706) NullPointerException occurs when trying to create a table in schema SESSION
[ http://issues.apache.org/jira/browse/DERBY-1706?page=comments#action_12435075 ] Suresh Thalamati commented on DERBY-1706: - Hi Mamta, just a general question: Why is it necessary to allow users to create a non-temporary tables in the session schema , when the schema is not created explicitly ? Thanks -suresh NullPointerException occurs when trying to create a table in schema SESSION --- Key: DERBY-1706 URL: http://issues.apache.org/jira/browse/DERBY-1706 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Sun JDK 1.4.2 Reporter: Yip Ng Assigned To: Mamta A. Satoor Priority: Minor Attachments: DERBY1706NPEwithSessionSchemaV1diff.txt, DERBY1706NPEwithSessionSchemaV2diff.txt, DERBY1706NPEwithSessionSchemaV3diff.txt NPE occurs when attempting to create a table in schema session: ij version 10.2 ij connect 'jdbc:derby:wombat;create=true' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentica tion. ij set schema session; 0 rows inserted/updated/deleted ij create table t1 (i int); ERROR XJ001: Java exception: ': java.lang.NullPointerException'. derby.log: 2006-08-16 20:49:02.765 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.2.1.0 beta - (430903): instance c013800d-010d-18be-88cf-0013f010 on database directory C:\work3\derby\tests\derby-10.2.1.0\lib\wombat Database Class Loader started - derby.database.classpath='' 2006-08-16 20:49:17.312 GMT Thread[main,5,main] (XID = 122), (SESSIONID = 0), (DATABASE = wombat), (DRDAID = null), Cleanup action starting 2006-08-16 20:49:17.312 GMT Thread[main,5,main] (XID = 122), (SESSIONID = 0), (DATABASE = wombat), (DRDAID = null), Failed Statement is: create table t1 (i int) java.lang.NullPointerException at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(Unknown Source) at org.apache.derby.impl.sql.compile.DDLStatementNode.getSchemaDescriptor(Unknown Source) at org.apache.derby.impl.sql.compile.DDLStatementNode.getSchemaDescriptor(Unknown Source) at org.apache.derby.impl.sql.compile.CreateTableNode.referencesSessionSchema(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.referencesSessionSchema(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) Cleanup action completed 2006-08-16 20:49:55.312 GMT: Shutting down instance c013800d-010d-18be-88cf-0013f010 sysinfo: -- Java Information -- Java Version:1.4.2_12 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\j2re1.4.2_12 Java classpath: derby.jar;derbytools.jar;. OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: Yip Java user home: C:\Documents and Settings\Yip Java user dir: C:\work3\derby\tests\derby-10.2.1.0\lib java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\work3\derby\tests\derby-10.2.1.0\lib\derby.jar] 10.2.1.0 beta - (430903) [C:\work3\derby\tests\derby-10.2.1.0\lib\derbytools.jar] 10.2.1.0 beta - (430903 ) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.1.0 - (430903) Found support for locale: [es] version: 10.2.1.0 - (430903) Found support for locale: [fr] version: 10.2.1.0 - (430903) Found support for locale: [it]
[jira] Commented: (DERBY-801) Allow parallel access to data files.
[
http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12434613 ]
Suresh Thalamati commented on DERBY-801:
Thanks for working on this issue, Anders. I really like your solution to solve
this issue. Patch is very good, I have only few minor comments/questions.
I am really sorry for not reviewing it sooner.
RAFContainerFactory.java
Logic in this new class seems to be deciding whether to load RafContainer.java
or
the RafContainer4.java based on the JVM. I am not sure, if this logic is
necessary here. Did you consider using basic services to load the java classes
specific to a JVM ?
I think basic services has support to boot a specific factory implementation
based on the JVM using modules.properties. For example in the current
scenario, one can extend BaseDataFileFactory.java class to
implement newContainerObject(), which will return the RafContainer4( ..). add
the new class to modules.properties to boot only on versions =jdk14.
In RafContainer4.java :
-
1) I think following import is not needed.
+import java.io.*;
2) Is it really necessary to rewind() the buffers in readFull/writeFull ? From
what I understood,
there is a new ByteBuffer object being created on both read/write page
methods.
+dstBuffer.rewind(); // Reset buffer position before we start read
and
+srcBuffer.rewind(); // Reset buffer position before we start writing.
3) do we really need the following method ?
+final protected FileChannel getChannel() {
+return ourChannel;
+}
4) I noticed, there is new encryption buffer created on every writePage() call,
if the database is encrypted. This may cause jvm peak memory usage increase,
when there is a checkpoint, if there are lot of dirty pages in the cache and
if garbage collection is not happening fast enough. I hope this does not
lead to out of memory errors!
We may need to implement some kind of scheme, that will help in reuse of
the encryption buffers.
5) I am ok with readPage() and writePage() routines in RafContainer4.java.
just curious , if you considered implementing new read/write..etc calls in
the RafContainer4.java using file channel and just wrapper methods in the
RafContainer.java using the existing random access file, instead of
overriding readPage()/writePage() ...etc.
6) Please file a JIRA to enhance StorageFactory interfaces to support NIO.
/suresh
Allow parallel access to data files.
Key: DERBY-801
URL: http://issues.apache.org/jira/browse/DERBY-801
Project: Derby
Issue Type: Improvement
Components: Performance, Store
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2,
10.1.2.0, 10.1.2.1
Environment: Any
Reporter: Øystein Grøvlen
Assigned To: Anders Morken
Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch,
DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
Derby currently serializes accesses to a data file. For example, the
implementation of RAFContainer.readPage is as follows:
synchronized (this) { // 'this' is a FileContainer, i.e. a file object
fileData.seek(pageOffset); // fileData is a RandomAccessFile
fileData.readFully(pageData, 0, pageSize);
}
I have experiemented with a patch where I have introduced several file
descriptors (RandomAccessFile objects) per RAFContainer. These are
used for reading. The principle is that when all readers are busy, a
readPage request will create a new reader. (There is a maximum number
of readers.) With this patch, throughput was improved by 50% on
linux. For more discussion on this, see
http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
The challenge with the suggested approach is to make a mechanism to
limit the number of open file descpriptors. Mike Matrigali has
suggested to use the existing CacheManager infrastructure for this
purpose. For a discussion on that, see:
http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
