Re: Grant -revoke (464) and future backwards compat
Daniel John Debrunner wrote: CREATE SCHEMA - only create schema matching user's name - good for now, forwards compatible with the future where permission to create any schema could be granted explicitly. Does this mean that we will only allow one schema per user? That seems like a severe limitation. I guess I am missing something. -- Øystein Grøvlen, Senior Staff Engineer Sun Microsystems, Database Technology Group Trondheim, Norway
[jira] Commented: (DERBY-800) derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout
[ http://issues.apache.org/jira/browse/DERBY-800?page=comments#action_12367164 ] Øystein Grøvlen commented on DERBY-800: --- What I have done with this issue is that I have run the test with some tracing to see what caused the lock timeouts. I have not quite got to the bottom of it, but so far it seems to me that it is not a deadlock scenario, but just timeouts due to long queues on the dictionary lock. (See below for more info). Since creating 100 tables in parallel is not a common scenario, I am not sure whether it is worth the effort to attempt fix this so the test runs cleanly. ( The test was made to test a fix (Derby-230) that I do not think is very likely to reoccur.) I have suggested on derby-dev take we should just remove the test from derbyall. No one has protested so I will create a patch to do that. derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout -- Key: DERBY-800 URL: http://issues.apache.org/jira/browse/DERBY-800 Project: Derby Type: Bug Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Øystein Grøvlen Priority: Critical I have seen ConcurrentImplicitCreateSchema.java get a lock timeout periodically and it occurred in the posted sun tests for build 365391 http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/365391-derbylang_diff.txt (I don't know how long this link will last. Below is the diff) * Diff file derbylang/derbylang/ConcurrentImplicitCreateSchema.diff *** Start: ConcurrentImplicitCreateSchema jdk1.5.0_04 derbylang:derbylang 2006-01-02 20:03:09 *** 2 del Closed connection 3 del Test ConcurrentImplicitCreateSchema PASSED 3 add ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:550)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScan(B2IRowLocking3.java:135)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could
[jira] Updated: (DERBY-800) derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout
[ http://issues.apache.org/jira/browse/DERBY-800?page=all ] Øystein Grøvlen updated DERBY-800: -- Attachment: derby-800.diff Attached derby-800.diff which removes lang/ConcurrentImplicitCreateSchema.java from derbyall. Files that are changed: M java/testing/org/apache/derbyTesting/functionTests/suites/derbylang.runall M java/testing/org/apache/derbyTesting/functionTests/suites/derbynetmats.runall derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout -- Key: DERBY-800 URL: http://issues.apache.org/jira/browse/DERBY-800 Project: Derby Type: Bug Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Øystein Grøvlen Priority: Critical Attachments: derby-800.diff I have seen ConcurrentImplicitCreateSchema.java get a lock timeout periodically and it occurred in the posted sun tests for build 365391 http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/365391-derbylang_diff.txt (I don't know how long this link will last. Below is the diff) * Diff file derbylang/derbylang/ConcurrentImplicitCreateSchema.diff *** Start: ConcurrentImplicitCreateSchema jdk1.5.0_04 derbylang:derbylang 2006-01-02 20:03:09 *** 2 del Closed connection 3 del Test ConcurrentImplicitCreateSchema PASSED 3 add ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:550)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScan(B2IRowLocking3.java:135)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could
[jira] Updated: (DERBY-800) derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout
[ http://issues.apache.org/jira/browse/DERBY-800?page=all ] Øystein Grøvlen updated DERBY-800: -- Other Info: [Patch available] derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout -- Key: DERBY-800 URL: http://issues.apache.org/jira/browse/DERBY-800 Project: Derby Type: Bug Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Øystein Grøvlen Priority: Critical Attachments: derby-800.diff I have seen ConcurrentImplicitCreateSchema.java get a lock timeout periodically and it occurred in the posted sun tests for build 365391 http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/365391-derbylang_diff.txt (I don't know how long this link will last. Below is the diff) * Diff file derbylang/derbylang/ConcurrentImplicitCreateSchema.diff *** Start: ConcurrentImplicitCreateSchema jdk1.5.0_04 derbylang:derbylang 2006-01-02 20:03:09 *** 2 del Closed connection 3 del Test ConcurrentImplicitCreateSchema PASSED 3 add ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:550)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScan(B2IRowLocking3.java:135)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not
Regression Test Failure! - Derby 379197 - Sun DBTG
[Auto-generated mail] *Derby* 379197/2006-02-20 19:45:57 CET *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 4637633 0 101.24% CYGWIN_NT-5.1_i686-unknown 3637634 0 104.34% CYGWIN_NT-5.2_i686-unknown 3637634 0 101.19% Linux-2.4.21-27.ELsmp_i686-athlon 1637636 099.54% Linux-2.6.14-1.1644_FC4_i686-i686 3637634 092.48% SunOS-5.10_i86pc-i386 4637633 0 116.89% SunOS-5.10_sun4u-sparc 3637634 0 103.37% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-379197.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/379197.html *Jvm: 1.4* 5635630 197.68% CYGWIN_NT-5.1_i686-unknown 1635634 1 102.54% Linux-2.4.21-27.ELsmp_i686-athlon NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 4635631 198.16% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-379197.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/379197.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/379197.txt (All results in http://www.multinet.no/~solberg/public/Apache/index.html)
Re: [jira] Commented: (DERBY-273) The derbynet/dataSourcePermissions_net.java test fails intermittently
Hello Kathey. Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-273?page=comments#action_12367073 ] Kathey Marsden commented on DERBY-273: -- I don't think for this test any of the console output needs to go to System.out. The test is not for testing the console output. Your comments noticed me the idea that console output of network server is not designed to be used as output of test program. I continue under that idea and see output of problematic error messages again. Best regards. -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Re: [jira] Commented: (DERBY-273) The derbynet/dataSourcePermissions_net.java test fails intermittently
Hello . A little unhappy news ... I call begin method of NetworkServer with PrintWriter for file and execute until ShutdownException was found. Almost all shutdown message was printed only to PrintWriter , however, next part was printed to System.out. The part which was printed to System.out : agentThread[DRDAConnThread_5,5,derby.daemons] Now, It seems to be needed to use System.setOut/setErr ... Best regards. TomohitoNakayama wrote: Hello Kathey. Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-273?page=comments#action_12367073 ] Kathey Marsden commented on DERBY-273: -- I don't think for this test any of the console output needs to go to System.out. The test is not for testing the console output. Your comments noticed me the idea that console output of network server is not designed to be used as output of test program. I continue under that idea and see output of problematic error messages again. Best regards. -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Re: [jira] Updated: (DERBY-800) derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout
I'll review, testa nd commit this one. Øystein Grøvlen (JIRA) wrote (2006-02-21 10:09:25): [ http://issues.apache.org/jira/browse/DERBY-800?page=all ] Øystein Grøvlen updated DERBY-800: -- Other Info: [Patch available] derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout -- Key: DERBY-800 URL: http://issues.apache.org/jira/browse/DERBY-800 Project: Derby Type: Bug Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Øystein Grøvlen Priority: Critical Attachments: derby-800.diff I have seen ConcurrentImplicitCreateSchema.java get a lock timeout periodically and it occurred in the posted sun tests for build 365391 http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/365391-derbylang_diff.txt (I don't know how long this link will last. Below is the diff) * Diff file derbylang/derbylang/ConcurrentImplicitCreateSchema.diff *** Start: ConcurrentImplicitCreateSchema jdk1.5.0_04 derbylang:derbylang 2006-01-02 20:03:09 *** 2 del Closed connection 3 del Test ConcurrentImplicitCreateSchema PASSED 3 add ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:550)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScan(B2IRowLocking3.java:135)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested
[jira] Commented: (DERBY-796) jdbc 4.0 specific Blob and Clob method support
[
http://issues.apache.org/jira/browse/DERBY-796?page=comments#action_12367183 ]
Knut Anders Hatlen commented on DERBY-796:
--
Thanks for the improved patch, Narayanan! You have addressed most of
my concerns, but there is still one issue:
ClientJDBCObjectFactory (in the am package) has a lot of references to
classes in the net package. There should not be any dependencies from
am to net.
And while you're at it, there's a white-space change in
am/PreparedStatement.java that wasn't in your previous patch:
public class PreparedStatement extends Statement
implements java.sql.PreparedStatement,
-PreparedStatementCallbackInterface {
+PreparedStatementCallbackInterface{
jdbc 4.0 specific Blob and Clob method support
--
Key: DERBY-796
URL: http://issues.apache.org/jira/browse/DERBY-796
Project: Derby
Type: New Feature
Components: JDBC
Versions: 10.2.0.0
Environment: jdbc 4.0 on all platforms
Reporter: V.Narayanan
Assignee: V.Narayanan
Priority: Minor
Fix For: 10.2.0.0
Attachments: ClientFrameworkExplanation_1.txt,
ClientFrameworkExplanation_2.txt, ClientFramework_Explanation.txt, lob.diff,
lob_1.diff, lob_2.diff, lob_3.diff, lob_4.diff, lob_4.stat, lob_5.diff,
lob_5.stat, lob_6.diff, lob_6.stat
--
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-482) GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section.
[ http://issues.apache.org/jira/browse/DERBY-482?page=comments#action_12367187 ] John H. Embretsen commented on DERBY-482: - Hmm, I did a quick check myself, and found that I got roughly the same error as Mamta when trying to view the HTML document with Internet Explorer 6. With Opera the html renders just fine, and with Firefox it is displayed as unrendered xml, with the message This XML file does not appear to have any style information associated with it. The document tree is shown below.. When I try to Save target as..., even Opera seems to think it's an xml document. However, if I do save it as html, I am able to open the local copy (as rendered html) in all browsers. I looked, but could not find anything (different from other derby-doc htmls) in the source (html and the patch) that may explain why this happens to this particular document. GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section. Key: DERBY-482 URL: http://issues.apache.org/jira/browse/DERBY-482 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Mamta A. Satoor Attachments: ctoolsimportidentitycol.html, derby482.diff Tomohito added support for import into identity columns by adding GENERATED BY DEFAULT option. This is documented in the Reference Guide but not in the Tools and Utilites Guide which is where a user would look for details on import. IMHO, there should be information about this in Importing into tables with identity columns section in Tools and Utilities Guide. -- 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-960) Client xa prepare returns XA_OK instead of XA_RDONLY for a read only transaction
[
http://issues.apache.org/jira/browse/DERBY-960?page=comments#action_12367188 ]
Kathey Marsden commented on DERBY-960:
--
Suresh pointed out to me that this change caused the following new failures
testing derbynetclientmats with 10.1 client and 10.2 server:
(jdk15/IBM131/IBM142 client 10.1) derbynetclientmats:
derbynetclientmats/derbynetclientmats.fail:jdbcapi/xaSimplePositive.sql
derbynetclientmats/derbynetclientmats.fail:jdbcapi/xaStateTran.sql
both tests failed with following diff:
IJ ERROR: XA_RDONLY
I will port this fix to 10.1 which will resolve the failures on the latest
version of 10.1 but it will continue to fail with older clients.There was a
discussion about whether to bump the DRDA maintenance version to make this work
with older clients but the consensus was that anyone using XA will need both
the client and server changes.
(see earlier comments in this issue).
Client xa prepare returns XA_OK instead of XA_RDONLY for a read only
transaction
-
Key: DERBY-960
URL: http://issues.apache.org/jira/browse/DERBY-960
Project: Derby
Type: Bug
Components: Network Client
Versions: 10.1.2.3, 10.1.3.0, 10.2.0.0, 10.1.2.2
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.3
Attachments: ReadOnlyTran.zip, derby960_preview.diff
Client xa prepare returns XA_OK instead of XA_RDONLY for a read only
transaction
The code below checks the return value of XaResource.prepare to decide
whether to commit the transaction. The prepare return value is XA_OK ( 0)
for client when it should be XA_RDONLY(3)
Djava ReadOnlyTran derbycli
10.2.0.0 alpha
Apache Derby
Apache Derby Network Client JDBC Driver
table already exists
==: 1
XAResource.XA_RDONLY3
XAResource.XA_OK0
prp1 is: 0
Exception in thread main org.apache.derby.client.am.XaException: XAER_NOTA
: Error executing a XAResource.commit(), Server returned XAER_NOTA
at
org.apache.derby.client.net.NetXAResource.throwXAException(NetXAResource.java:728)
at
org.apache.derby.client.net.NetXAResource.commit(NetXAResource.java:216)
at ReadOnlyTran.main(ReadOnlyTran.java:94)
Caused by: org.apache.derby.client.am.SqlException: Error executing a
XAResource.commit(), Server returned XAER_NOTA
at
org.apache.derby.client.net.NetXAResource.xaRetValErrorAccumSQL(NetXAResource.java:976)
at
org.apache.derby.client.net.NetXAResource.commit(NetXAResource.java:204)
... 1 more
D
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.sql.XAConnection;
import javax.transaction.xa.XAException;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;
import com.ibm.db2.jcc.DB2Xid;
class ReadOnlyTran
{
public static void main (String args [])throws Exception
{
//org.apache.derby.jdbc.ClientConnectionPoolDataSource ds = new
org.apache.derby.jdbc.ClientConnectionPoolDataSource();
org.apache.derby.jdbc.ClientXADataSource ds = new
org.apache.derby.jdbc.ClientXADataSource();
//org.apache.derby.jdbc.EmbeddedXADataSource ds = new
//org.apache.derby.jdbc.EmbeddedXADataSource();
Connection conn = null;
ds.setDatabaseName(sample);
ds.setTraceFile(trace.out);
ds.setConnectionAttributes(create=true);
conn = ds.getConnection();
PreparedStatement ps1 = null;
try
{
DatabaseMetaData md = conn.getMetaData() ;
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());
ps1 = conn.prepareStatement(CREATE TABLE TAB1(COL1 INT NOT
NULL));
ps1.executeUpdate();
System.out.println(done creating table);
conn.commit ();
} catch (SQLException x)
{
System.out.println (table already exists);
}
XAConnection pc1 = ds.getXAConnection();
XAResource xar1 = pc1.getXAResource();
Xid xid1 = createXid(11);
xar1.start(xid1, XAResource.TMNOFLAGS);
Connection conn1 = pc1.getConnection();
doSelect(conn1, 50);
//doInsert(conn1);
conn1.close();
xar1.end(xid1, XAResource.TMSUCCESS);
int prp1 = xar1.prepare(xid1);
System.out.println(XAResource.XA_RDONLY +
XAResource.XA_RDONLY);
System.out.println(XAResource.XA_OK +
XAResource.XA_OK);
System.out.println(prp1 is: + prp1);
// Commit transaction
if (prp1 ==
[jira] Created: (DERBY-1014) Make tests less sensitive to pre-fetching
Make tests less sensitive to pre-fetching - Key: DERBY-1014 URL: http://issues.apache.org/jira/browse/DERBY-1014 Project: Derby Type: Sub-task Components: Test Reporter: Knut Anders Hatlen Assigned to: Knut Anders Hatlen Priority: Minor Some tests are very sensitive to changes in pre-fetching, either because they call SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS() which displays the number of rows seen, or because a failure that normally is exposed when calling ResultSet.next() is exposed when calling Statement.execute(). Most of these tests are not testing when or how much data is pre-fetched. If we make the tests less sensitive to pre-fetching, it is easier to catch the real regressions when changing the way Derby is pre-fetching data. Also, patches in that area of the code will be smaller (fewer test changes) and easier to review. -- 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
Re: [jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
Deepa Remesh wrote: Thanks John. I'll also try to see if I can get a machine to setup DOTS after I finish my current iteration of the patch. Good. By the way, I am planning to create a small proof of concept app - independent from, but inspired by, the infamous DOTS test case. This way we don't have to run the whole DOTS machinery to reproduce the error I was seeing. I'll either add it to your derbyStress.java or post it to Jira as an independent repro program. -- John
[web] Request for website updates for nightly builds and javadoc
I think it would be good from the download page to point to the nightly builds that Ole posts for users to try out if they want to be daring: 10.2 - http://www.multinet.no/~solberg/public/Apache/Derby/builds/ 10.1 - http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ I also think it would be good for the public API javadoc to be linked from the Manuals page. I know it is linked from the Papers page, but I don't think users would tend to go there. Three questions: 1) Does anyone see any issue with linking these builds to the download page with suitable disclaimers? 2) I noticed the 10.1 page talks about the alpha flag which I think is not applicable. 3) Should I fiile this as 2 Jira issues or lump them together as one? Kathey
Re: [web] Request for website updates for nightly builds and javadoc
Kathey Marsden wrote: I also think it would be good for the public API javadoc to be linked from the Manuals page. I know it is linked from the Papers page, but I don't think users would tend to go there. Actually the API is linked, I was just being blind. The only request is for the builds.
Re: RowLocation validation, for holdable SUR
I will modify the suggestion somewhat. I think first, that offline compress is not a problem, even for the holdable SUR. Since offline compress moves the records to another container, the SUR cursors should detect that container they use is no longer valid, when renavigating to the row. If a client of store moves a row by deleting and inserting it somewhere else, the SUR should not find the row when trying to do renavigate to it for update or delete, and can give an error. What our problem is, is the case where a row is inserted into the container, and it gets the same RowLocation as a row which we have read into the SUR. The row which we had previously read into the SUR, must have been deleted and purged for this to happen. In addition, as far as I can see, for a new row to get the same RowLocation as a row previously deleted and purged, the page for the row, must have been truncated, and recreated. So then how can we detect that a page has been recreated ? We could i.e use a timestamp on the create/recreate time of the page. This timestamp could be read by the SUR as it reads the RowLocation (so we do not need to change the impl. of RowLocation), and again, we would probably need to change the header for the page, so that we can store the timestamp. Andreas Mike Matrigali wrote: Some questions: o row locations are stored in every index row. Are you proposing a data level upgrade of every row in all databases? o What is your proposal in the case of soft upgrade (note I believe not supporting holdable SUR in soft upgrade is an option). o The hard case is the compress case that removes pages from a file, in this case there is no place to store the version number that you are relying on (the same problem in the current system why truncte can't support non-reusable rowlocations). o Is it worth the on disk and in memory overhead to every row location to support holdable SUR? I believe one of the operations you are trying to address is when a client of store moves a record by deleting and inserting it. This is what compress does today. So if we start with row loc A pointing at row A, and compress deletes row A and inserts it at row loc B. In both the current and new system access to A will return an error, but neither will know that the row has been moved to a new ID. Is this ok? If the current system always supported non-reusable row id's, even in the truncate case do you have what you need? Again this will not prevent clients of store from moving a row by inserting and deleting it somewhere else. Andreas Korneliussen wrote: Following is a proposal to ensure that a client of store can verify the validity of a RowLocation. A RowLocation has become invalid if a store operation has caused it to point to another row or to a non-existent position (deleted row or non-existing page/record-id). I think we need a mechanism to detect that a RowLocation has become invalid in order to implement *holdable* SUR. To do this, I would propose: - The RowLocation object should contain a version number for the page. - A version number should be stored in the header for a Page - Whenever an operation which may invalidate row-locations is executed, the version number for the page is updated. These operations include online/offline compress. - When navigating to a RowLocation which has invalid version number, the store may fail (i.e return false) The page header for a stored page, currently has a number of fields which are intended for future use, and it seems that it is possible to use these fields without breaking backward compatibility. I noticed one of the fields in the header is named generation (from StoredPage.java): * 4 bytes integergeneration generation number of this page(FUTURE USE) * 4 bytes integerprevGeneration previous generation of page (FUTURE USE) Could I use the generation field for this, or has it been reserved for something else ? Alternatively, I could use one of the other long fields reserved for future use. Any comments ? Thanks --Andreas
Re: [web] Request for website updates for nightly builds and javadoc
Kathey Marsden wrote: I think it would be good from the download page to point to the nightly builds that Ole posts for users to try out if they want to be daring: 10.2 - http://www.multinet.no/~solberg/public/Apache/Derby/builds/ 10.1 - http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ It would be easy for http://db.apache.org/derby/derby_downloads.html to point to an index of nightly builds on http://www.multinet.no/~solberg/public/ It's hard to automatically rebuild the web site nightly to point to each specific new build (more details below). I also think it would be good for the public API javadoc to be linked from the Manuals page. I know it is linked from the Papers page, but I don't think users would I think this point is resolved in your followup post. Three questions: 1) Does anyone see any issue with linking these builds to the download page with suitable disclaimers? Linking to each new build is a problem because the web site would need to be automatically regenerated, committed, then checked out on people.apache.org. (Details are in http://www.apache.org/dev/project-site.html ; what isn't said is the ASF infrastructure volunteers depend on built pages being checked into svn so in the case of a system failure they can simply check the built websites out of svn, possibly on a new machine.) Linking from http://db.apache.org/derby/derby_downloads.html to another index page of the builds outside the Derby web site shouldn't be a problem -- and disclaimers are needed. I think there might be an ASF policy wrt to nightly builds. I'll chase it down if somebody doesn't beat me to it. 2) I noticed the 10.1 page talks about the alpha flag which I think is not applicable. Which page? could you provide the complete URL? 3) Should I fiile this as 2 Jira issues or lump them together as one? I think maybe a more generic issue is how to make nightly builds available. -jean Kathey
Re: [web] Request for website updates for nightly builds and javadoc
Jean T. Anderson wrote: Kathey Marsden wrote: I think it would be good from the download page to point to the nightly builds that Ole posts for users to try out if they want to be daring: 10.2 - http://www.multinet.no/~solberg/public/Apache/Derby/builds/ 10.1 - http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ It would be easy for http://db.apache.org/derby/derby_downloads.html to point to an index of nightly builds on http://www.multinet.no/~solberg/public/ It's hard to automatically rebuild the web site nightly to point to each specific new build (more details below). These two lings are farily static I think: The 10.1 builds are at: http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ The trunk builds (10.2) are at: http://www.multinet.no/~solberg/public/Apache/Derby/builds/ and should be separately linked from the downloads page. We wouldn't need a new link until 10.2 branched. 2) I noticed the 10.1 page talks about the alpha flag which I think is not applicable. Which page? could you provide the complete URL? I was talking about Ole's 10.1 build page: http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ Which in the description has information about both the branches and the trunk, so just before the build listing you see in red. *Warning!* The alpha version tag explicitly disables upgrade in Derby. It is not a big deal really but might be a little confusing to someone looking to download 10.1 to check out a fix.
[jira] Commented: (DERBY-870) Update documentation on setting up LDAP user authentication.
[
http://issues.apache.org/jira/browse/DERBY-870?page=comments#action_12367230 ]
Sunitha Kambhampati commented on DERBY-870:
---
I tried with 'no' additional jars and I could get LDAP authentication to work
with derby with
ibm142,jdk142,jdk15
But with jdk141, ibm141, and ibm13- I get the following error
This is what is in the DirContext.
{java.naming.provider.url=ldaps://xyz.abc.com:636,
ava.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
java.naming.security.authentication=simple}
ERROR 08004: Connection refused : javax.naming.NamingException: Cannot parse
url: ldaps://xyz.abc.com:636 [Root exception is java.net.MalformedURLException:
Not an LDAP URL: ldaps://xyz.abc.com:636]
Not sure if this is related to since this is secure ldap.
Has anyone else tried it out with 1.3.1 or 1.4.1 vms successfully. If so,
please share your results. Thanks.
Update documentation on setting up LDAP user authentication.
Key: DERBY-870
URL: http://issues.apache.org/jira/browse/DERBY-870
Project: Derby
Type: Improvement
Components: Documentation
Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.0,
10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2
Reporter: Sunitha Kambhampati
Priority: Minor
http://db.apache.org/derby/docs/dev/devguide/rdevcsecure608.html
This talks about needing jndi.jar , ldap.jar and providerUtil.jar.
I think this is not true anymore with the latest 1.4.2 vms atleast, and
should be updated. It seems like with 1.4.2 etc, all these classes are in
rt.jar. Need to verify and the doc needs to be updated.
--
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-1015) Define interface between network server and engine through Java interfaces.
Define interface between network server and engine through Java interfaces. --- Key: DERBY-1015 URL: http://issues.apache.org/jira/browse/DERBY-1015 Project: Derby Type: Improvement Components: JDBC Reporter: Daniel John Debrunner Assigned to: Daniel John Debrunner Fix For: 10.2.0.0 API between the network server and engine is not well defined, leading to inconsistent multiple ways of handling the different objects returned, such as reflection, explicit casting etc. This in turn has lead to bugs such as DERBY-966 . DERBY-1005, and DERBY-1006, and access to underlying objects by the application that should be hidden. Define interfaces, such as EngineConnection, that both EmbedConnection and BrokeredConnection implement. Thus the network server can rely on the fact that any connection it obtains will implement EngineConnection, and call the required methods through that interface. Most likely will need EngineConnection, EnginePreparedStatement and EngineResultSet.. These interfaces would be internal to derby and not exposed to applications. -- 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-482) GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section.
[ http://issues.apache.org/jira/browse/DERBY-482?page=comments#action_12367232 ] Jeff Levitt commented on DERBY-482: --- Thats so strange. It did it to me too, and I looked at the original copy on my local machine and it looked fine. Mamtam when you try again, maybe just force it to an html extension by stripping the .xml it adds to the file name. Then open it up again and you should read it fine. GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section. Key: DERBY-482 URL: http://issues.apache.org/jira/browse/DERBY-482 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Mamta A. Satoor Attachments: ctoolsimportidentitycol.html, derby482.diff Tomohito added support for import into identity columns by adding GENERATED BY DEFAULT option. This is documented in the Reference Guide but not in the Tools and Utilites Guide which is where a user would look for details on import. IMHO, there should be information about this in Importing into tables with identity columns section in Tools and Utilities Guide. -- 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-515) Network Server should log server start and shutdown time to derby.log
[ http://issues.apache.org/jira/browse/DERBY-515?page=comments#action_12367233 ] Deepa Remesh commented on DERBY-515: Suresh pointed out to me that this change caused the following failure in derbynetclientmats with 10.1 client and 10.2 server: derbynetclientmats/derbynetmats/derbynetmats.fail:derbynet/testProperties.java: ( Shutdown successful. 6a6 Apache Derby Network Server - 10.2.0.0 alpha shutdown at xxFILTERED-TIMESTAMPxGMT 11 del ) The diff is in the shutdown message. The test executes a process to shutdown the network server that it started. This process currently dumps results to standard out. I am planning to change this test to make the shutdown process not write to the standard output. The test can use execCmd instead of execCmdDumpResults method for the shutdown process. I will submit a patch for this in a while. Network Server should log server start and shutdown time to derby.log - Key: DERBY-515 URL: http://issues.apache.org/jira/browse/DERBY-515 Project: Derby Type: Improvement Components: Network Server Versions: 10.1.2.0, 10.2.0.0 Reporter: Kathey Marsden Assignee: Deepa Remesh Fix For: 10.2.0.0 Attachments: derby-515-patch2-v1.diff, derby-515-patch2-v1.status, derby-515-v2.diff, derby-515-v2.status Network server currently only reports the start and stop of network server to the console output and does not print an associated timestamp. It would be helpful if the start and stop times of network server were recorded in the derby.log, so there would not be a need to check t the console output. -- 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
Re: [web] Request for website updates for nightly builds and javadoc
Kathey Marsden wrote: Jean T. Anderson wrote: Kathey Marsden wrote: I think it would be good from the download page to point to the nightly builds that Ole posts for users to try out if they want to be daring: 10.2 - http://www.multinet.no/~solberg/public/Apache/Derby/builds/ 10.1 - http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ It would be easy for http://db.apache.org/derby/derby_downloads.html to point to an index of nightly builds on http://www.multinet.no/~solberg/public/ It's hard to automatically rebuild the web site nightly to point to each specific new build (more details below). These two lings are farily static I think: The 10.1 builds are at: http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ The trunk builds (10.2) are at: http://www.multinet.no/~solberg/public/Apache/Derby/builds/ and should be separately linked from the downloads page. We wouldn't need a new link until 10.2 branched. I agree that we should just have links from the Derby downloads page to my Derby/builds/ and Derby-10.1/builds/ pages. When we get another branch we will have to do some manual updates both to the Derby download page and my pages anyway. 2) I noticed the 10.1 page talks about the alpha flag which I think is not applicable. Which page? could you provide the complete URL? I was talking about Ole's 10.1 build page: http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ Which in the description has information about both the branches and the trunk, so just before the build listing you see in red. *Warning!* The alpha version tag explicitly disables upgrade in Derby. It is not a big deal really but might be a little confusing to someone looking to download 10.1 to check out a fix. I have now removed the text referring to the development trunk from the 10.1 branch builds page. (I did it manually on the page, and it will be created this way next time we have a 10.1 branch update/build.) -- Ole Solberg, Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Grant -revoke (464) and future backwards compat
Satheesh Bandaram wrote: Oystein Grovlen - Sun Norway wrote: Daniel John Debrunner wrote: CREATE SCHEMA - only create schema matching user's name - good for now, forwards compatible with the future where permission to create any schema could be granted explicitly. Does this mean that we will only allow one schema per user? That seems like a severe limitation. I guess I am missing something. This is where Francois's work on system privileges is needed. Current grant/revoke proposal only deals with access privileges to existing objects, like ability to grant/revoke select, insert, delete, update or allow references/triggers to tables and execute privilege to routines. What is sorely needed is ability to grant/revoke system/database access and I thought Francois was working on this. Any status Francois? Until these system privileges are ready, current proposal limits accesses that would cause forward compatibility issues. Except that it doesn't, I believe we need additional restrictions on table and routine creation. If sqlStandard mode allows unrestricted schema creation now, this would cause issues in the future where existing applications may need to change or we have to introduce another property like what is being done now. Current legacy authorization model is not compatible with standard model or what Derby might really want to support, but at the same time, we can't drop support for it because of existing applications. I'm not sure why legacy mode keeps being dragged into this discussion, or why folks see it as not compatible. I see it as compatible, it's an additional layer of authorization at the incoming connection level. It has three modes in sqlStandard mode: - no access - No connection acceess, regardless of any granted privs. - read-only access - Connection made read only, read-only access limited to granted privs. No write access regardless of granted privs. It is similar to the application calling conn.setReadOnly(true). - full-access - Access limited to granted privs. I believe Dan is try to ensure current proposal doesn't create any future compatibility issues, even if in the short term, Derby's new capabilities are restrictive. Yep, exactly what I'm trying to ensure. Thanks, Dan.
Re: RowLocation validation, for holdable SUR
The SUR should not know anything about the underlying implementation of the access method getting the row, so having it read a timestamp from page does not work. If the timestamp is not in the rowlocation, we could add a get a timestamp for row at this rowlocation, but forcing two trips to the store for every row is a overhead. Rather than discuss implementation it would be nice to understand the minimum necessary services needed to be provided by the access method. Do the same interfaces need to be provided by VTI's? At least for your use I think the timestamp need only guarantee to be different after a truncate from previous version on page. Since you are ok with invalidating the SUR in the case of offline compress, what about invalidating the SUR in the case of online compress also? One way to do this is for the system catalogs to maintain a table version number, which would be guaranteed to not change while any sort of table intent lock was present. Any operation which either copied rows to another container or truncated the table would bump the version number. And holdable cursors would need to recheck the version number after losing the lock at commit time. The downside is that some SUR's are invalidated that didn't need to be, but compress kicking in, in a holdable cursor in the time between a commit and then next operation in the cursor is going to be a rare event. The upside is that there is no extra per row overhead in the system for the normal case. There already exists a ddl invalidation scheme for invalidating query plans, maybe this existing structure could be used to invalidate SUR's after the commit? Andreas Korneliussen wrote: I will modify the suggestion somewhat. I think first, that offline compress is not a problem, even for the holdable SUR. Since offline compress moves the records to another container, the SUR cursors should detect that container they use is no longer valid, when renavigating to the row. If a client of store moves a row by deleting and inserting it somewhere else, the SUR should not find the row when trying to do renavigate to it for update or delete, and can give an error. What our problem is, is the case where a row is inserted into the container, and it gets the same RowLocation as a row which we have read into the SUR. The row which we had previously read into the SUR, must have been deleted and purged for this to happen. In addition, as far as I can see, for a new row to get the same RowLocation as a row previously deleted and purged, the page for the row, must have been truncated, and recreated. So then how can we detect that a page has been recreated ? We could i.e use a timestamp on the create/recreate time of the page. This timestamp could be read by the SUR as it reads the RowLocation (so we do not need to change the impl. of RowLocation), and again, we would probably need to change the header for the page, so that we can store the timestamp. Andreas Mike Matrigali wrote: Some questions: o row locations are stored in every index row. Are you proposing a data level upgrade of every row in all databases? o What is your proposal in the case of soft upgrade (note I believe not supporting holdable SUR in soft upgrade is an option). o The hard case is the compress case that removes pages from a file, in this case there is no place to store the version number that you are relying on (the same problem in the current system why truncte can't support non-reusable rowlocations). o Is it worth the on disk and in memory overhead to every row location to support holdable SUR? I believe one of the operations you are trying to address is when a client of store moves a record by deleting and inserting it. This is what compress does today. So if we start with row loc A pointing at row A, and compress deletes row A and inserts it at row loc B. In both the current and new system access to A will return an error, but neither will know that the row has been moved to a new ID. Is this ok? If the current system always supported non-reusable row id's, even in the truncate case do you have what you need? Again this will not prevent clients of store from moving a row by inserting and deleting it somewhere else. Andreas Korneliussen wrote: Following is a proposal to ensure that a client of store can verify the validity of a RowLocation. A RowLocation has become invalid if a store operation has caused it to point to another row or to a non-existent position (deleted row or non-existing page/record-id). I think we need a mechanism to detect that a RowLocation has become invalid in order to implement *holdable* SUR. To do this, I would propose: - The RowLocation object should contain a version number for the page. - A version number should be stored in the header for a Page - Whenever an operation which may invalidate row-locations is executed, the version number for the page is updated. These
[jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
[
http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12367235 ]
Kathey Marsden commented on DERBY-210:
--
There was a separate thread on this issue on the list where concerns were
voiced about doing the result set cleanup work in finalize and maybe creating
another thread to do that.
I talked with Deepa a bit on IRC about the impact of submitting her patch as is
without the result set cleanup.
The summary is.
Before Deepa's patch 4:
- No statements or result sets get cleaned up until the end of the connection
unless explicitly closed
After Deepa's patch 4:
- No statements or result sets get cleaned up until the end of the connection
unless explicitly closed.
After Deepa's planned patch 5:
Most statements and result sets get cleaned up automatically.
So, I am of the opinion that Deepa's patch can go in as is and another Jira
entry filed for the result set cleanup. Her planned work is a huge
improvement over the current state. She does not need to include the result
set cleanup in her patch for DERBY-210
Network Server will leak prepared statements if not explicitly closed by the
user until the connection is closed
Key: DERBY-210
URL: http://issues.apache.org/jira/browse/DERBY-210
Project: Derby
Type: Bug
Components: Network Client
Reporter: Kathey Marsden
Assignee: Deepa Remesh
Attachments: DOTS_ATCJ2_Derby-noPatch.png, DOTS_ATCJ2_Derby-withPatch.png,
derby-210-patch1.diff, derby-210-patch2.diff, derby-210-patch2.status,
derby-210-patch3.diff, derby-210-patch4-v2.diff, derby-210-patch4-v2.status,
derby-210-v2-draft.diff, derby-210-v2-draft.status, derbyStress.java
Network server will not garbage collect prepared statements that are not
explicitly closed by the user. So a loop like this will leak.
...
PreparedStatement ps;
for (int i = 0 ; i numPs; i++)
{
ps = conn.prepareStatement(selTabSql);
rs =ps.executeQuery();
while (rs.next())
{
rs.getString(1);
}
rs.close();
// I'm a sloppy java programmer
//ps.close();
}
To reproduce run the attached program
java derbyStress
Both client and server will grow until the connection is closed.
It is likely that the fix for this will have to be in the client. The client
does not send protocol to close the prepared statement, but rather reuses the
PKGNAMCSN on the PRPSQLSTT request once the prepared statement has been
closed. This is how the server knows to close the old statement and create a
new one.
--
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-819) Provide JDBC4 SQLException subclasses support in Embedded driver
[ http://issues.apache.org/jira/browse/DERBY-819?page=all ] Anurag Shekhar updated DERBY-819: - Attachment: derby-819_3.diff Main changed I have made in this patch since the last submission I have moved back the exception methods of Utils. Now the exceptionFactory is a static member of Utils which is initialized during declaration itself so when this will never be null hence eliminating the possibility of NPE This variable is overwritten by SQLException40 instance by Driver40 during boot. Merged the two method of SQLExceptionFactory40. In newly created exception pointed the stack trace to root cause (if there is another exception available) Other issues Fixed the copyright dates. Modified test code to check SQLSTATE Added comments in SQLException40 class and getSQLException method of the same. Open Issues derbyall has many failure (even without this patch) when executed with jdk1.6. I will be creating a jira issue for this. After these changes all the tests which are comparing the exception thrown or printing the exception will fail. Provide JDBC4 SQLException subclasses support in Embedded driver Key: DERBY-819 URL: http://issues.apache.org/jira/browse/DERBY-819 Project: Derby Type: Sub-task Components: JDBC Environment: all Reporter: Anurag Shekhar Assignee: Anurag Shekhar Priority: Minor Attachments: .derby-819_2.stat, derby-819-onlyforreview.diff, derby-819.diff, derby-819_2.diff, derby-819_3.diff, stat.out -- 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-1016) javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of
XA_PROTO on a prepared transaction
--
Key: DERBY-1016
URL: http://issues.apache.org/jira/browse/DERBY-1016
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.2.0.0, 10.1.2.3, 10.1.3.0
Reporter: Kathey Marsden
javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of
XA_PROTO on a prepared transaction
I posted a question to derby-dev about this and heard no response so am
assuming it is indeed a bug.
in the XA+
specification, it seems like xa_forget should only be valid for a
heuristically completed transaction, so should be XAER_PROTO
and not XAER_NOTA.
In xaStateTran.sql we have this case:
-- get back into prepared state
xa_start xa_noflags 50;
insert into xastate values(2);
xa_end xa_success 50;
xa_prepare 50;
select * from global_xactTable where gxid is not null order by gxid;
-- the following should error XAER_NOTA
xa_forget 50;
The user code I am looking at handles forget like this. They expect
XAER_PROTO in this case.
try {
xaRes.forget(xidList[i]);
System.out.print(XA-Transaction [ + (i+1) + ]
Forgotten. \n );
} catch (XAException XAeForget) {
if ( XAeForget.errorCode ==
XAException.XAER_PROTO ) {
System.out.print(XA-Transaction [ + (i+1)
+ ] not heuristically completed yet - Rolling Back instead. \n );
xaRes.rollback(xidList[i]);
System.out.print(XA-Transaction [ + (i+1)
+ ] Rolled Back. \n );
}
if ( XAeForget.getMessage() != null ) {
System.out.println(XAException +
XAeForget.getMessage() );
--
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-690) Add scrollable, updatable, insensitive result sets
[ http://issues.apache.org/jira/browse/DERBY-690?page=all ]
Fernanda Pizzorno updated DERBY-690:
Attachment: DERBY-690-v1.diff
DERBY-690-v1.stat
This is a first cut at a patch for SUR. It corresponds to the description
uploaded earlier as
http://issues.apache.org/jira/secure/attachment/12323122/writeup-v1.html. It
passes derbyall,
and although the many tests written under DERBY-934 have been enabled as part
of this patch,
more tests will be written.
There remains an issue around in-line compress, see the discussion in this mail
thread:
http://www.nabble.com/conflict-detection-strategies-t1120376.html#a2960144
Add scrollable, updatable, insensitive result sets
--
Key: DERBY-690
URL: http://issues.apache.org/jira/browse/DERBY-690
Project: Derby
Type: New Feature
Components: JDBC
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
Priority: Minor
Attachments: DERBY-690-v1.diff, DERBY-690-v1.stat, SURChanges-v1.pdf,
sur-proposal.txt, writeup-v1.html
JDBC result sets are created with three properties: type, concurrency
and holdability. The type can be one of TYPE_FORWARD_ONLY,
TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE. The concurrency can
be one of CONCUR_READ_ONLY and CONCUR_UPDATABLE. The holdability can
be one of HOLD_CURSORS_OVER_COMMIT and CLOSE_CURSORS_AT_COMMIT.
JDBC allows the full cross product of these. SQL 2003 prohibits the
combination {TYPE_SCROLL_INSENSITIVE, CONCUR_UPDATABLE}, but this
combination is supported by some vendors, notably Oracle.
Currently, Derby supports JDBC result sets in a limited
way. Holdability is supported. Furthermore, the following is
supported:
- forward-only, read-only
- forward-only, updatable (update, delete, but not insert)
Also, in the network driver, support for some data types
conversions is missing.
- scroll insensitive, read-only
We (Fernanda and Andreas will cooperate with me on this) propose a
plan to add support for the combination:
- scroll insensitive, updatable
for both the embedded driver and the network client driver.
As a part of this we would also like to add the missing insert
operation to the {forward-only, updatable} result sets (JIRA-100), and
remove the requirement for an explicit FOR UPDATE clause in the SQL
query to achieve updatability if CONCUR_UPDATABLE is specified
(JIRA-231).
The full proposal text is uploaded as an attachment, including a proposed
functional specification.
This JIRA will be used to track sub-issues for this effort. The sub-issues
will be linked back to this issue.
--
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-690) Add scrollable, updatable, insensitive result sets
[ http://issues.apache.org/jira/browse/DERBY-690?page=all ]
Fernanda Pizzorno updated DERBY-690:
Other Info: [Patch available]
Add scrollable, updatable, insensitive result sets
--
Key: DERBY-690
URL: http://issues.apache.org/jira/browse/DERBY-690
Project: Derby
Type: New Feature
Components: JDBC
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
Priority: Minor
Attachments: DERBY-690-v1.diff, DERBY-690-v1.stat, SURChanges-v1.pdf,
sur-proposal.txt, writeup-v1.html
JDBC result sets are created with three properties: type, concurrency
and holdability. The type can be one of TYPE_FORWARD_ONLY,
TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE. The concurrency can
be one of CONCUR_READ_ONLY and CONCUR_UPDATABLE. The holdability can
be one of HOLD_CURSORS_OVER_COMMIT and CLOSE_CURSORS_AT_COMMIT.
JDBC allows the full cross product of these. SQL 2003 prohibits the
combination {TYPE_SCROLL_INSENSITIVE, CONCUR_UPDATABLE}, but this
combination is supported by some vendors, notably Oracle.
Currently, Derby supports JDBC result sets in a limited
way. Holdability is supported. Furthermore, the following is
supported:
- forward-only, read-only
- forward-only, updatable (update, delete, but not insert)
Also, in the network driver, support for some data types
conversions is missing.
- scroll insensitive, read-only
We (Fernanda and Andreas will cooperate with me on this) propose a
plan to add support for the combination:
- scroll insensitive, updatable
for both the embedded driver and the network client driver.
As a part of this we would also like to add the missing insert
operation to the {forward-only, updatable} result sets (JIRA-100), and
remove the requirement for an explicit FOR UPDATE clause in the SQL
query to achieve updatability if CONCUR_UPDATABLE is specified
(JIRA-231).
The full proposal text is uploaded as an attachment, including a proposed
functional specification.
This JIRA will be used to track sub-issues for this effort. The sub-issues
will be linked back to this issue.
--
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
Re: [web] Request for website updates for nightly builds and javadoc
Ole Solberg wrote: Kathey Marsden wrote: Jean T. Anderson wrote: Kathey Marsden wrote: I think it would be good from the download page to point to the nightly builds that Ole posts for users to try out if they want to be daring: 10.2 - http://www.multinet.no/~solberg/public/Apache/Derby/builds/ 10.1 - http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ It would be easy for http://db.apache.org/derby/derby_downloads.html to point to an index of nightly builds on http://www.multinet.no/~solberg/public/ It's hard to automatically rebuild the web site nightly to point to each specific new build (more details below). These two lings are farily static I think: The 10.1 builds are at: http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ The trunk builds (10.2) are at: http://www.multinet.no/~solberg/public/Apache/Derby/builds/ and should be separately linked from the downloads page. We wouldn't need a new link until 10.2 branched. I agree that we should just have links from the Derby downloads page to my Derby/builds/ and Derby-10.1/builds/ pages. When we get another branch we will have to do some manual updates both to the Derby download page and my pages anyway. infrequent updates to the derby web aren't any problem at all -- and any committer can make them, incidently. I'm looking at http://www.apache.org/dev/release.html, and here's the wording regarding builds: # Builds are not official Apache releases. All releases require due process and official approval. Distributions which are not officially blessed are termed builds. * Nightly Builds are simply built from HEAD once a day. These are intended to allow those without access to Apache code repositories to access the latest code. Of course, these come with no guarantees concerning quality. How about this wording for a new Nightly Builds section on http://db.apache.org/derby/derby_downloads.html . Unofficial nightly builds are available from the links below: * 10.1 : http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ * development trunk: http://www.multinet.no/~solberg/public/Apache/Derby/builds/ Nightly builds are generated automatically and there is no guarantee that they will actually work! Production systems should *always* use the official release. tight enough? need additional wording? -jean
Re: [web] Request for website updates for nightly builds and javadoc
Jean T. Anderson wrote: How about this wording for a new Nightly Builds section on http://db.apache.org/derby/derby_downloads.html . Unofficial nightly builds are available from the links below: * 10.1 : http://www.multinet.no/~solberg/public/Apache/Derby-10.1/builds/ * development trunk: http://www.multinet.no/~solberg/public/Apache/Derby/builds/ Nightly builds are generated automatically and there is no guarantee that they will actually work! Production systems should *always* use the official release. tight enough? need additional wording? We might want to say something about optional build components that are always present in official releases may not be present in these unofficial builds, e.g. JSR169 suppport, OSGi support, JDBC 4.0 support. I tried downloading a build from Ole's site to see what was in the jars, but it was really slow so I gave up. Though what's true for Ole's build may not be true for someone else's builds in the future. Dan.
[jira] Commented: (DERBY-482) GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section.
[ http://issues.apache.org/jira/browse/DERBY-482?page=comments#action_12367241 ] Mamta A. Satoor commented on DERBY-482: --- Jeff, I looked through the html file and have couple comments. 1)I don't understand the line in the first paragraph You can specify the GENERATED ALWAYS or GENERATED BY DEFAULT options when using the procedure to define identity column values. I haven't paid close attention to changes to SYSCS_UTIL.SYSCS_IMPORT_DATA, but I don't think it needs to know if it is dealing with GENERATED ALWAYS or GENERATED BY DEFAULT. In fact, from what I know, there is no way to specify to the SYSCS_UTIL.SYSCS_IMPORT_DATA procedure whether it is dealing with GENERATED ALWAYS or GENERATED BY DEFAULT. 2)IMHO, the information on GENERATED ALWAYS and GENERATED BY DEFAULT is not flowing very smoothly on the html page. I like the format for GENERATED ALWAYS where we first give the create table sql and then 2 different forms of import files and how to use the import procedure to import from them. In addition to these 2 examples for GENERATED ALWAYS, I think it will be good to add another example where user is trying to import from a file with values for identity column data and import procedure uses that data for GENERATED ALWAYS. Such an import will fail for GENERATED ALWAYS. eg Robert,1,45.2,J Mike,2,23.4,I Leo,3,23.4,I CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'TAB1', 'C1,C2,C3,C4' , '1,2,3,4','empfile.del',null, null,null,0) We should keep similar format for GENERATED BY DEFAULT. Show create table sql for it, and then show couple examples of import data file where the value is specified for the column or DEFAULT is specified for the column or the column values are not included in the import data file. And then for these various import files, show how data can be imported into the table with GENERATED BY DEFAULT. GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section. Key: DERBY-482 URL: http://issues.apache.org/jira/browse/DERBY-482 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Mamta A. Satoor Attachments: ctoolsimportidentitycol.html, derby482.diff Tomohito added support for import into identity columns by adding GENERATED BY DEFAULT option. This is documented in the Reference Guide but not in the Tools and Utilites Guide which is where a user would look for details on import. IMHO, there should be information about this in Importing into tables with identity columns section in Tools and Utilities Guide. -- 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-1017) locking issue with a select statement using an order by clause
locking issue with a select statement using an order by clause
--
Key: DERBY-1017
URL: http://issues.apache.org/jira/browse/DERBY-1017
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.0.2.0
Environment: Windows XP Professional operating system and Java2 platform using
JDK 5.0
Reporter: Mark H. Kaplan
I am using the network version of Derby (version 10 - the network version). I
am running two threads. The first thread is doing an insert into a table but
not committing. The second table is doing a select statement. When the select
statement has an order by clause, it will not complete but when it does not
have the order by clause, it completes while the first thread is sleeping.
The database contains one table with five columns. I have tried having an index
on the order by column but that does not seem to make a difference. I have not
set any isolation level on the database so it is using the default of
TRANSACTION_READ_COMMITTED.
The insert statement in the first thread looks like:
INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract) VALUES
('999-99-', 'last', 'first', 'xxx-', 0)
The select statement in the second thread looks like:
SELECT au_id, au_lname, au_fname, phone, contract FROM authors where au_lname =
'xxx' ORDER BY au_fname
MORE INFORMATION --
My order by select statement does timeout with the error 40XL1. I tried putting
an index on the au_fname but that did not make a difference
I have included locking data which I retrieved by running a SELECT * FROM NEW
org.apache.derby.diag.LockTable() AS LT while the second thread was doing its
SELECT statement. I do not understand the data but I thought that it might give
you a better idea of what is going on. I have also included the database sql
script that creates the database table and the two sql statements that I am
running in separate threads to give you a better idea of what I am doing. Let
me know if you need any other information:
(Locking Data)
XID |TYPE |MODE |TAB |LOCK |STATE |TABLETYPE |LOCK |INDEXNAME
===
302 |ROW |X |AUTHORS |(2,18) |GRANT |T |1 |null
302 |ROW |X |AUTHORS |(1,7) |GRANT |T |1 |null
304 |ROW |S |AUTHORS |(1,7) |WAIT |T |0 |null
302 |TABLE |IX |AUTHORS |Tablelock |GRANT |T |3 |null
304 |TABLE |IS |AUTHORS |Tablelock |GRANT |T |1 |null
(SQL Script)
DROP TABLE authors;
CREATE TABLE authors (
au_id VARCHAR(32) NOT NULL,
au_lname VARCHAR(40) ,
au_fname VARCHAR(20) ,
phone VARCHAR(12) ,
contract INT NOT NULL,
PRIMARY KEY (au_id)
);
CREATE INDEX firstnameindex ON authors (au_fname);
(SQL Statements)
Thread 1 - INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract)
VALUES ('999-99-', 'last', 'first', 'xxx-', 0)
Thread2 - SELECT au_id, au_lname, au_fname, phone, contract FROM authors where
au_lname = 'xxx' ORDER BY au_fname
--
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-1018) Client xa Statement.getConnection and DatabaseMetadata.getConnection returns underlying NetXAConnection instead of Logical connection
Client xa Statement.getConnection and DatabaseMetadata.getConnection returns underlying NetXAConnection instead of Logical connection -- Key: DERBY-1018 URL: http://issues.apache.org/jira/browse/DERBY-1018 Project: Derby Type: Bug Components: Network Client Versions: 10.2.0.0, 10.1.2.3, 10.1.3.0 Reporter: Kathey Marsden Fix For: 10.1.3.0 For client XA a Statement.getConnection() and DatabaseMetaData.getConnection() return a NetXAConnection instead of a LogicalConnection. e.g. for a connection obtained from a ClientXADataSource: Statement stmt = conn.createStatement(); System.out.println(conn: + conn + stmt.getConnection(): + stmt.getConnection()); yields conn:[EMAIL PROTECTED]():[EMAIL PROTECTED] -- 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-992) A corner case bug and missing optimization in ScrollInsensitiveResultSet
[ http://issues.apache.org/jira/browse/DERBY-992?page=all ]
Dag H. Wanvik updated DERBY-992:
Attachment: derby-992-1.diff
derby-992-1.stat
derby-992-1.{stat,diff} contains a patch for this issue. I have added
a test for the case described under a) above and run derbyall with only
these errors showing up, neither of which seem related to the patch:
grantRevoke.sql
syscat.sql
xaSimplePositive.sql
NSinSameJVM.java
DerbyNetNewServer.java
syscat.sql
NSinSameJVM.java
DerbyNetNewServer.java
syscat.sql
Can someone please look at this? It is a small patch ;-)
A corner case bug and missing optimization in ScrollInsensitiveResultSet
Key: DERBY-992
URL: http://issues.apache.org/jira/browse/DERBY-992
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.0.2.1
Environment: Solaris 10/x86, Sun VM 1.4.2
Reporter: Dag H. Wanvik
Priority: Minor
Attachments: Main.java, derby-992-1.diff, derby-992-1.stat
a) For a scrollable, insensitive result set (read-only) which is
empty, ResultSet#afterLast should have no effect, but erroneously
sets the internal variable afterLast to true, so that a sunsequent
call to ResultSet#isAfterLast will return 'true' in the embedded
client. It does not happen on the client driver, because it seems
to do some double book-keeping for this case.
b) In ScrollInsensitiveResultSet#getNextRowCore and #getAbsoluteRow,
there are missing checks will cause unnecessary read (attempts)
from underlying result set even if end has been seen already.
Both would be nice to fix in preparation for DERBY-690...
--
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-992) A corner case bug and missing optimization in ScrollInsensitiveResultSet
[ http://issues.apache.org/jira/browse/DERBY-992?page=all ] Dag H. Wanvik updated DERBY-992: Other Info: [Patch available] A corner case bug and missing optimization in ScrollInsensitiveResultSet Key: DERBY-992 URL: http://issues.apache.org/jira/browse/DERBY-992 Project: Derby Type: Bug Components: JDBC Versions: 10.0.2.1 Environment: Solaris 10/x86, Sun VM 1.4.2 Reporter: Dag H. Wanvik Priority: Minor Attachments: Main.java, derby-992-1.diff, derby-992-1.stat a) For a scrollable, insensitive result set (read-only) which is empty, ResultSet#afterLast should have no effect, but erroneously sets the internal variable afterLast to true, so that a sunsequent call to ResultSet#isAfterLast will return 'true' in the embedded client. It does not happen on the client driver, because it seems to do some double book-keeping for this case. b) In ScrollInsensitiveResultSet#getNextRowCore and #getAbsoluteRow, there are missing checks will cause unnecessary read (attempts) from underlying result set even if end has been seen already. Both would be nice to fix in preparation for DERBY-690... -- 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-992) A corner case bug and missing optimization in ScrollInsensitiveResultSet
[ http://issues.apache.org/jira/browse/DERBY-992?page=all ] Dag H. Wanvik reassigned DERBY-992: --- Assign To: Dag H. Wanvik A corner case bug and missing optimization in ScrollInsensitiveResultSet Key: DERBY-992 URL: http://issues.apache.org/jira/browse/DERBY-992 Project: Derby Type: Bug Components: JDBC Versions: 10.0.2.1 Environment: Solaris 10/x86, Sun VM 1.4.2 Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Priority: Minor Attachments: Main.java, derby-992-1.diff, derby-992-1.stat a) For a scrollable, insensitive result set (read-only) which is empty, ResultSet#afterLast should have no effect, but erroneously sets the internal variable afterLast to true, so that a sunsequent call to ResultSet#isAfterLast will return 'true' in the embedded client. It does not happen on the client driver, because it seems to do some double book-keeping for this case. b) In ScrollInsensitiveResultSet#getNextRowCore and #getAbsoluteRow, there are missing checks will cause unnecessary read (attempts) from underlying result set even if end has been seen already. Both would be nice to fix in preparation for DERBY-690... -- 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
Re: Grant -revoke (464) and future backwards compat
Daniel John Debrunner wrote: Satheesh Bandaram wrote: Until these system privileges are ready, current proposal limits accesses that would cause forward compatibility issues. Except that it doesn't, I believe we need additional restrictions on table and routine creation. In sqlStandard mode, the proposal only allows for creating tables and routines in their own Schema and no where else. I thought this is too restrictive already :-) , but makes sense that unless someone grants ability to create tables in their schema, Derby shouldn't allow that. Currently there is no way to grant privilege to create tables... What future scenario do you see where schema owners don't have ability to create tables or routines in their own schema, by default? It may be possible that Derby would allow granting/revoking table or routine privileges in the future, but default behavior for a schema owner would be to have this privilege by default? If sqlStandard mode allows unrestricted schema creation now, this would cause issues in the future where existing applications may need to change or we have to introduce another property like what is being done now. Current legacy authorization model is not compatible with standard model or what Derby might really want to support, but at the same time, we can't drop support for it because of existing applications. I'm not sure why "legacy" mode keeps being dragged into this discussion, or why folks see it as "not compatible". If current or legacy mode is compatible with sqlStandard mode, would there be a need to add new property, derby.database.sqlAuthorization? I understand going forward defaultConnectionMode can be seen as compatible with standard model as additional layer of authorization, but I see there is a break from 10.1 model to 10.2. I see it as compatible, it's an additional layer of authorization at the incoming connection level. - full-access - Access limited to granted privs. The way I see it, Derby is essentially changing full-access meaning... from "read/write access to every object in the database" to "read/write access to objects owned or been granted limited access to" in sqlStandard mode. This would force existing applications to change to adapt to sqlStandard mode, right? If so, we have an incompatibility. Satheesh
New Main class for derbytools.jar
Following Dan's suggestion to be able to run ij with the -jar command, I thought why not have derbytools.jar itself be runnable with the -jar command, and have it switch on the tools, and pass the remaining arguments to the specific tool. Attached is the patch. If there are no objections, I'll file a JIRA for tracking purposes, and commit this. andrew toolsrun.diff Description: Binary data
Re: Grant -revoke (464) and future backwards compat
On 2/21/06, Satheesh Bandaram [EMAIL PROTECTED] wrote: Oystein Grovlen - Sun Norway wrote: Daniel John Debrunner wrote: CREATE SCHEMA - only create schema matching user's name - good for now, forwards compatible with the future where permission to create any schema could be granted explicitly. Does this mean that we will only allow one schema per user? That seems like a severe limitation. I guess I am missing something. This is where Francois's work on system privileges is needed. Current grant/revoke proposal only deals with access privileges to existing objects, like ability to grant/revoke select, insert, delete, update or allow references/triggers to tables and execute privilege to routines. What is sorely needed is ability to grant/revoke system/database access and I thought Francois was working on this. Any status Francois? I'll be posting more information soon. Until these system privileges are ready, current proposal limits accesses that would cause forward compatibility issues. If sqlStandard mode allows unrestricted schema creation now, this would cause issues in the future where existing applications may need to change or we have to introduce another property like what is being done now. Current legacy authorization model is not compatible with standard model or what Derby might really want to support, but at the same time, we can't drop support for it because of existing applications. I believe Dan is try to ensure current proposal doesn't create any future compatibility issues, even if in the short term, Derby's new capabilities are restrictive. Satheesh
[jira] Commented: (DERBY-1017) locking issue with a select statement using an order by clause
[
http://issues.apache.org/jira/browse/DERBY-1017?page=comments#action_12367245 ]
Stan Bradbury commented on DERBY-1017:
--
Original issue reported to the Cloudscape forum at:
http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?forum=370thread=108128cat=19
I have requested that the source code for the reproduction be attached to this
issue.
locking issue with a select statement using an order by clause
--
Key: DERBY-1017
URL: http://issues.apache.org/jira/browse/DERBY-1017
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.0.2.0
Environment: Windows XP Professional operating system and Java2 platform
using JDK 5.0
Reporter: Mark H. Kaplan
I am using the network version of Derby (version 10 - the network version). I
am running two threads. The first thread is doing an insert into a table but
not committing. The second table is doing a select statement. When the select
statement has an order by clause, it will not complete but when it does not
have the order by clause, it completes while the first thread is sleeping.
The database contains one table with five columns. I have tried having an
index on the order by column but that does not seem to make a difference. I
have not set any isolation level on the database so it is using the default
of TRANSACTION_READ_COMMITTED.
The insert statement in the first thread looks like:
INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract) VALUES
('999-99-', 'last', 'first', 'xxx-', 0)
The select statement in the second thread looks like:
SELECT au_id, au_lname, au_fname, phone, contract FROM authors where au_lname
= 'xxx' ORDER BY au_fname
MORE INFORMATION --
My order by select statement does timeout with the error 40XL1. I tried
putting an index on the au_fname but that did not make a difference
I have included locking data which I retrieved by running a SELECT * FROM
NEW org.apache.derby.diag.LockTable() AS LT while the second thread was
doing its SELECT statement. I do not understand the data but I thought that
it might give you a better idea of what is going on. I have also included the
database sql script that creates the database table and the two sql
statements that I am running in separate threads to give you a better idea of
what I am doing. Let me know if you need any other information:
(Locking Data)
XID |TYPE |MODE |TAB |LOCK |STATE |TABLETYPE |LOCK |INDEXNAME
===
302 |ROW |X |AUTHORS |(2,18) |GRANT |T |1 |null
302 |ROW |X |AUTHORS |(1,7) |GRANT |T |1 |null
304 |ROW |S |AUTHORS |(1,7) |WAIT |T |0 |null
302 |TABLE |IX |AUTHORS |Tablelock |GRANT |T |3 |null
304 |TABLE |IS |AUTHORS |Tablelock |GRANT |T |1 |null
(SQL Script)
DROP TABLE authors;
CREATE TABLE authors (
au_id VARCHAR(32) NOT NULL,
au_lname VARCHAR(40) ,
au_fname VARCHAR(20) ,
phone VARCHAR(12) ,
contract INT NOT NULL,
PRIMARY KEY (au_id)
);
CREATE INDEX firstnameindex ON authors (au_fname);
(SQL Statements)
Thread 1 - INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract)
VALUES ('999-99-', 'last', 'first', 'xxx-', 0)
Thread2 - SELECT au_id, au_lname, au_fname, phone, contract FROM authors
where au_lname = 'xxx' ORDER BY au_fname
--
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
Grant/Revoke subtask - EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER
Hi, Satheesh has added the parser support for EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER on a routine (function or procedure). eg from lang/grantRevoke.sql test CREATE PROCEDURE AUTH_TEST.addUserUtility(IN userName VARCHAR(50), IN permission VARCHAR(22)) LANGUAGE JAVA PARAMETER STYLE JAVAEXTERNAL SECURITY INVOKEREXTERNAL NAME 'org.apache.derby.database.UserUtility.add '; But this information about INVOKER vs DEFINER doesn't get stored in any system table. I am looking into finishing up this subtask to see what may be requiredduringcompile, executeandupgrade timesfor this subtask. Willsend more information as I make more progress. thanks, Mamta ps Will it be useful to create a subtask of Derby-464 to keep track of this work?
Re: Grant -revoke (464) and future backwards compat
On 2/21/06, Satheesh Bandaram [EMAIL PROTECTED] wrote: Daniel John Debrunner wrote: Satheesh Bandaram wrote: Until these system privileges are ready, current proposal limits accesses that would cause forward compatibility issues. Except that it doesn't, I believe we need additional restrictions on table and routine creation. In sqlStandard mode, the proposal only allows for creating tables and routines in their own Schema and no where else. I thought this is too restrictive already :-) , but makes sense that unless someone grants ability to create tables in their schema, Derby shouldn't allow that. Currently there is no way to grant privilege to create tables... What future scenario do you see where schema owners don't have ability to create tables or routines in their own schema, by default? It may be possible that Derby would allow granting/revoking table or routine privileges in the future, but default behavior for a schema owner would be to have this privilege by default? I need to check again and I thought object creation privileges were granted to some schema owner if that schema had been created explictly with the CREATE SCHEMA AUTHORIZATION DDL. If sqlStandard mode allows unrestricted schema creation now, this would cause issues in the future where existing applications may need to change or we have to introduce another property like what is being done now. Current legacy authorization model is not compatible with standard model or what Derby might really want to support, but at the same time, we can't drop support for it because of existing applications. I'm not sure why legacy mode keeps being dragged into this discussion, or why folks see it as not compatible. If current or legacy mode is compatible with sqlStandard mode, would there be a need to add new property, derby.database.sqlAuthorization? I understand going forward defaultConnectionMode can be seen as compatible with standard model as additional layer of authorization, but I see there is a break from 10.1 model to 10.2. Agreed - this additional layer has to be flagged in order to be turned on with its new semantics, no? I thought we had that new property (derby.database.sqlAuthorization) for that reason (and it can still be a layer on top of legacy) I see it as compatible, it's an additional layer of authorization at the incoming connection level. - full-access - Access limited to granted privs. The way I see it, Derby is essentially changing full-access meaning... from read/write access to every object in the database to read/write access to objects owned or been granted limited access to in sqlStandard mode. This would force existing applications to change to adapt to sqlStandard mode, right? If so, we have an incompatibility. That is correct. Once sqlStandard is enabled then legacy defined privileges become more like (specific) Roles for some users to be granted too - that's the way I see it. Satheesh
Re: New Main class for derbytools.jar
Andrew McIntyre wrote: Dan, expanding on your previous idea, what if we add a class to derbytools.jar as it's default run class that just switches on the available tools, then you can do: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook etc. +1 That's a very cool idea. Got to love that about open source development, throw out a half baked idea and someone else takes it a step further or a new direction and comes up with a great idea. Thanks, Dan.
Re: Grant -revoke (464) and future backwards compat
Satheesh Bandaram wrote: Daniel John Debrunner wrote: Satheesh Bandaram wrote: Until these system privileges are ready, current proposal limits accesses that would cause forward compatibility issues. Except that it doesn't, I believe we need additional restrictions on table and routine creation. In sqlStandard mode, the proposal only allows for creating tables and routines in their own Schema and no where else. I thought this is too restrictive already :-) , but makes sense that unless someone grants ability to create tables in their schema, Derby shouldn't allow that. Currently there is no way to grant privilege to create tables... What future scenario do you see where schema owners don't have ability to create tables or routines in their own schema, by default? It may be possible that Derby would allow granting/revoking table or routine privileges in the future, but default behavior for a schema owner would be to have this privilege by default? I looked at some other databases (Oracle, DB2, Postgres) and the typical model is to require a database level privilege to create tables or call an external routine. Create table I could possibly go either way on, but if we followed the de-facto standard model of other databases then we need a database level privilege. Creating an external routine would have all sorts of security concerns for a database owner, it's allowing a remote user to execute code on their system. Dan. Current legacy authorization model is not compatible with standard model or what Derby might really want to support, but at the same time, we can't drop support for it because of existing applications. I'm not sure why legacy mode keeps being dragged into this discussion, or why folks see it as not compatible. If current or legacy mode is compatible with sqlStandard mode, would there be a need to add new property, derby.database.sqlAuthorization? I understand going forward defaultConnectionMode can be seen as compatible with standard model as additional layer of authorization, but I see there is a break from 10.1 model to 10.2. I see it as compatible, it's an additional layer of authorization at the incoming connection level. - full-access - Access limited to granted privs. The way I see it, Derby is essentially changing full-access meaning... from read/write access to every object in the database to read/write access to objects owned or been granted limited access to in sqlStandard mode. This would force existing applications to change to adapt to sqlStandard mode, right? If so, we have an incompatibility. I think we are in agreement, but talking about different things. Introducing grant/revoke causes behaviour incompatible (when enabled) with previous releases. The connection based authorization model (noAccess, readOnly or full) by itself is not incompatible with grant/revoke. Dan.
Re: New Main class for derbytools.jar
On 2/21/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: Andrew McIntyre wrote: Dan, expanding on your previous idea, what if we add a class to derbytools.jar as it's default run class that just switches on the available tools, then you can do: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook etc. +1 That's a very cool idea. Great, let's take it one step further. Why don't we remove the frameworks directory. Completely. All the scripts there are for running the above three classes, and NetworkServerControl, which we also recently added the ability to run with -jar. Perhaps we could have a top-level bin directory with a simple readme on how to run the tools. What do you think? The downside is there's quite a bit of doc impact, but I'll be glad to help out with that. andrew
[jira] Created: (DERBY-1019) Add a main class to derbytools.jar so the tools can be run with java -jar
Add a main class to derbytools.jar so the tools can be run with java -jar - Key: DERBY-1019 URL: http://issues.apache.org/jira/browse/DERBY-1019 Project: Derby Type: Improvement Components: Tools Versions: 10.2.0.0, 10.1.3.0 Reporter: Andrew McIntyre Assigned to: Andrew McIntyre Fix For: 10.2.0.0 Attachments: toolsrun.diff Add a class to derbytools.jar as it's default run class that just switches on the available tools, so a user can run: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook -- 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-1019) Add a main class to derbytools.jar so the tools can be run with java -jar
[ http://issues.apache.org/jira/browse/DERBY-1019?page=all ] Andrew McIntyre updated DERBY-1019: --- Attachment: toolsrun.diff Add a main class to derbytools.jar so the tools can be run with java -jar - Key: DERBY-1019 URL: http://issues.apache.org/jira/browse/DERBY-1019 Project: Derby Type: Improvement Components: Tools Versions: 10.2.0.0, 10.1.3.0 Reporter: Andrew McIntyre Assignee: Andrew McIntyre Fix For: 10.2.0.0 Attachments: toolsrun.diff Add a class to derbytools.jar as it's default run class that just switches on the available tools, so a user can run: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook -- 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-1019) Add a main class to derbytools.jar so the tools can be run with java -jar
[ http://issues.apache.org/jira/browse/DERBY-1019?page=all ] Andrew McIntyre updated DERBY-1019: --- Attachment: toolsrun.stat Add a main class to derbytools.jar so the tools can be run with java -jar - Key: DERBY-1019 URL: http://issues.apache.org/jira/browse/DERBY-1019 Project: Derby Type: Improvement Components: Tools Versions: 10.2.0.0, 10.1.3.0 Reporter: Andrew McIntyre Assignee: Andrew McIntyre Fix For: 10.2.0.0 Attachments: toolsrun.diff, toolsrun.stat Add a class to derbytools.jar as it's default run class that just switches on the available tools, so a user can run: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook -- 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-960) Client xa prepare returns XA_OK instead of XA_RDONLY for a read only transaction
[ http://issues.apache.org/jira/browse/DERBY-960?page=all ]
Kathey Marsden resolved DERBY-960:
--
Resolution: Fixed
Checked in fix to 10.1
Author: kmarsden
Date: Tue Feb 21 08:19:30 2006
New Revision: 379513
URL: http://svn.apache.org/viewcvs?rev=379513view=rev
Client xa prepare returns XA_OK instead of XA_RDONLY for a read only
transaction
-
Key: DERBY-960
URL: http://issues.apache.org/jira/browse/DERBY-960
Project: Derby
Type: Bug
Components: Network Client
Versions: 10.1.2.3, 10.1.3.0, 10.2.0.0, 10.1.2.2
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.3
Attachments: ReadOnlyTran.zip, derby960_preview.diff
Client xa prepare returns XA_OK instead of XA_RDONLY for a read only
transaction
The code below checks the return value of XaResource.prepare to decide
whether to commit the transaction. The prepare return value is XA_OK ( 0)
for client when it should be XA_RDONLY(3)
Djava ReadOnlyTran derbycli
10.2.0.0 alpha
Apache Derby
Apache Derby Network Client JDBC Driver
table already exists
==: 1
XAResource.XA_RDONLY3
XAResource.XA_OK0
prp1 is: 0
Exception in thread main org.apache.derby.client.am.XaException: XAER_NOTA
: Error executing a XAResource.commit(), Server returned XAER_NOTA
at
org.apache.derby.client.net.NetXAResource.throwXAException(NetXAResource.java:728)
at
org.apache.derby.client.net.NetXAResource.commit(NetXAResource.java:216)
at ReadOnlyTran.main(ReadOnlyTran.java:94)
Caused by: org.apache.derby.client.am.SqlException: Error executing a
XAResource.commit(), Server returned XAER_NOTA
at
org.apache.derby.client.net.NetXAResource.xaRetValErrorAccumSQL(NetXAResource.java:976)
at
org.apache.derby.client.net.NetXAResource.commit(NetXAResource.java:204)
... 1 more
D
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.sql.XAConnection;
import javax.transaction.xa.XAException;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;
import com.ibm.db2.jcc.DB2Xid;
class ReadOnlyTran
{
public static void main (String args [])throws Exception
{
//org.apache.derby.jdbc.ClientConnectionPoolDataSource ds = new
org.apache.derby.jdbc.ClientConnectionPoolDataSource();
org.apache.derby.jdbc.ClientXADataSource ds = new
org.apache.derby.jdbc.ClientXADataSource();
//org.apache.derby.jdbc.EmbeddedXADataSource ds = new
//org.apache.derby.jdbc.EmbeddedXADataSource();
Connection conn = null;
ds.setDatabaseName(sample);
ds.setTraceFile(trace.out);
ds.setConnectionAttributes(create=true);
conn = ds.getConnection();
PreparedStatement ps1 = null;
try
{
DatabaseMetaData md = conn.getMetaData() ;
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());
ps1 = conn.prepareStatement(CREATE TABLE TAB1(COL1 INT NOT
NULL));
ps1.executeUpdate();
System.out.println(done creating table);
conn.commit ();
} catch (SQLException x)
{
System.out.println (table already exists);
}
XAConnection pc1 = ds.getXAConnection();
XAResource xar1 = pc1.getXAResource();
Xid xid1 = createXid(11);
xar1.start(xid1, XAResource.TMNOFLAGS);
Connection conn1 = pc1.getConnection();
doSelect(conn1, 50);
//doInsert(conn1);
conn1.close();
xar1.end(xid1, XAResource.TMSUCCESS);
int prp1 = xar1.prepare(xid1);
System.out.println(XAResource.XA_RDONLY +
XAResource.XA_RDONLY);
System.out.println(XAResource.XA_OK +
XAResource.XA_OK);
System.out.println(prp1 is: + prp1);
// Commit transaction
if (prp1 == XAResource.XA_OK)
xar1.commit(xid1, false);
// Close physical connection
pc1.close();
}
private static void doSelect(Connection conn, int deptno)
throws SQLException
{
Statement stmt = conn.createStatement();
ResultSet rset1 = stmt.executeQuery(select * from tab1);
while (rset1.next())
{
System.out.println(==: + rset1.getString(1));
}
stmt.close();
stmt = null;
}
private static void doInsert(Connection conn) throws SQLException
{
Statement stmt = conn.createStatement();
[jira] Updated: (DERBY-1017) locking issue with a select statement using an order by clause
[ http://issues.apache.org/jira/browse/DERBY-1017?page=all ]
Mark H. Kaplan updated DERBY-1017:
--
Attachment: derbyLocking.zip
attached is the source code for this issue. Ignore all of the commented lines
locking issue with a select statement using an order by clause
--
Key: DERBY-1017
URL: http://issues.apache.org/jira/browse/DERBY-1017
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.0.2.0
Environment: Windows XP Professional operating system and Java2 platform
using JDK 5.0
Reporter: Mark H. Kaplan
Attachments: derbyLocking.zip
I am using the network version of Derby (version 10 - the network version). I
am running two threads. The first thread is doing an insert into a table but
not committing. The second table is doing a select statement. When the select
statement has an order by clause, it will not complete but when it does not
have the order by clause, it completes while the first thread is sleeping.
The database contains one table with five columns. I have tried having an
index on the order by column but that does not seem to make a difference. I
have not set any isolation level on the database so it is using the default
of TRANSACTION_READ_COMMITTED.
The insert statement in the first thread looks like:
INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract) VALUES
('999-99-', 'last', 'first', 'xxx-', 0)
The select statement in the second thread looks like:
SELECT au_id, au_lname, au_fname, phone, contract FROM authors where au_lname
= 'xxx' ORDER BY au_fname
MORE INFORMATION --
My order by select statement does timeout with the error 40XL1. I tried
putting an index on the au_fname but that did not make a difference
I have included locking data which I retrieved by running a SELECT * FROM
NEW org.apache.derby.diag.LockTable() AS LT while the second thread was
doing its SELECT statement. I do not understand the data but I thought that
it might give you a better idea of what is going on. I have also included the
database sql script that creates the database table and the two sql
statements that I am running in separate threads to give you a better idea of
what I am doing. Let me know if you need any other information:
(Locking Data)
XID |TYPE |MODE |TAB |LOCK |STATE |TABLETYPE |LOCK |INDEXNAME
===
302 |ROW |X |AUTHORS |(2,18) |GRANT |T |1 |null
302 |ROW |X |AUTHORS |(1,7) |GRANT |T |1 |null
304 |ROW |S |AUTHORS |(1,7) |WAIT |T |0 |null
302 |TABLE |IX |AUTHORS |Tablelock |GRANT |T |3 |null
304 |TABLE |IS |AUTHORS |Tablelock |GRANT |T |1 |null
(SQL Script)
DROP TABLE authors;
CREATE TABLE authors (
au_id VARCHAR(32) NOT NULL,
au_lname VARCHAR(40) ,
au_fname VARCHAR(20) ,
phone VARCHAR(12) ,
contract INT NOT NULL,
PRIMARY KEY (au_id)
);
CREATE INDEX firstnameindex ON authors (au_fname);
(SQL Statements)
Thread 1 - INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract)
VALUES ('999-99-', 'last', 'first', 'xxx-', 0)
Thread2 - SELECT au_id, au_lname, au_fname, phone, contract FROM authors
where au_lname = 'xxx' ORDER BY au_fname
--
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
Re: New Main class for derbytools.jar
On 2/21/06, Andrew McIntyre [EMAIL PROTECTED] wrote: On 2/21/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: Andrew McIntyre wrote: Dan, expanding on your previous idea, what if we add a class to derbytools.jar as it's default run class that just switches on the available tools, then you can do: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook etc. +1 That's a very cool idea.Great, let's take it one step further. Why don't we remove the frameworks directory. Completely. All the scripts there are forrunning the above three classes, and NetworkServerControl, which wealso recently added the ability to run with -jar. Perhaps we couldhave a top-level bin directory with a simple readme on how to run the tools.What do you think? The downside is there's quite a bit of doc impact,but I'll be glad to help out with that.andrew +1 on that. I'm assuming the lib in (eg)lib/derbytools.jar is referring to the default location thus optional? Should also make implementing (a reworded)DERBY-667 - (test)more feasible (before it was hard to think of a way of making this work automatedon all platforms). And/but vice versa, if we are indeed doing this, we need to obviously definitely implement automated tests. Myrna
[jira] Closed: (DERBY-985) i18nTest fails with ''java.sql.SQLException: wrong locale' was thrown while evaluating an expression.' on Win2003
[ http://issues.apache.org/jira/browse/DERBY-985?page=all ] Myrna van Lunteren closed DERBY-985: Resolution: Duplicate Duplicate of https://issues.apache.org/jira/browse/DERBY-834 i18nTest fails with ''java.sql.SQLException: wrong locale' was thrown while evaluating an expression.' on Win2003 - Key: DERBY-985 URL: http://issues.apache.org/jira/browse/DERBY-985 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Microsoft(R) Windows(R) Server 2003, - 5.2.3790 Service Pack 1 Build 3790 - CYGWIN_NT-5.2 1.5.12(0.116/4/2) 2004-11-10 08:34 Cygwin, JVM: Sun Microsystems Inc. 1.5.0_04 Reporter: Ole Solberg Priority: Minor Signature: * Diff file i18nTest/i18nTest/urlLocale.diff *** Start: urlLocale jdk1.5.0_04 i18nTest:i18nTest 2006-02-14 21:45:58 *** 10a11,20 ERROR 38000: The exception 'java.sql.SQLException: wrong locale' was thrown while evaluating an expression. ERROR (no SQLState): wrong locale ij call checkRDefaultLoc(); no_NO ERROR 38000: The exception 'java.sql.SQLException: wrong_locale' was thrown while evaluating an expression. ERROR (no SQLState): wrong_locale ij disconnect; ij -- create a Swiss database connect 'swissdb;create=true;territory=fr_CH'; ij create procedure checkDatabaseLoc(in locale char(12)) parameter style java language java external name 'org.apache.derbyTesting.functionTests.tests.i18n.DefaultLocale.checkDatabaseLocale'; 12,19d21 ij call checkRDefaultLoc(); en_US 0 rows inserted/updated/deleted ij disconnect; ij -- create a Swiss database connect 'swissdb;create=true;territory=fr_CH'; ij create procedure checkDatabaseLoc(in locale char(12)) parameter style java language java external name 'org.apache.derbyTesting.functionTests.tests.i18n.DefaultLocale.checkDatabaseLocale'; 0 rows inserted/updated/deleted Test Failed. *** End: urlLocale jdk1.5.0_04 i18nTest:i18nTest 2006-02-14 21:46:44 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [CYGWIN_NT-5.2 i686-unknown] -- 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
Re: New Main class for derbytools.jar
On 2/21/06, Myrna van Lunteren [EMAIL PROTECTED] wrote: I'm assuming the lib in (eg) lib/derbytools.jar is referring to the default location thus optional? Correct. Should also make implementing (a reworded) DERBY-667 - (test) more feasible (before it was hard to think of a way of making this work automated on all platforms). And/but vice versa, if we are indeed doing this, we need to obviously definitely implement automated tests. Agreed. I'm having a hard time coming up with a good way to do that, though, besides pulling the location of the jar file out of the classpath, and then Runtime.exec()-ing the three java -jar commands with the tools jar and capturing the output. We could test the run class directly, but that doesn't test the manifest generation or that -jar actually works. Got any good ideas? I should also put the usage message into the locale file instead of hardcoding it in the file. andrew
[jira] Commented: (DERBY-834) i18n/urlLocale.sql test fails on Windows XP
[
http://issues.apache.org/jira/browse/DERBY-834?page=comments#action_12367254 ]
Myrna van Lunteren commented on DERBY-834:
--
This behavior is completely intended whenever the test is run on a machine that
does not have the en_US lcoale set.
observe this in the .sql:
---
create procedure checkDatabaseLoc(in locale char(12)) parameter style java
language java external name
'org.apache.derbyTesting.functionTests.tests.i18n.DefaultLocale.checkDatabaseLocale';
create procedure checkRDefaultLoc() parameter style java language java external
name
'org.apache.derbyTesting.functionTests.tests.i18n.DefaultLocale.checkRDefaultLocale';
-- this current database was created with the default locale
call checkDatabaseLoc('en_US');
call checkRDefaultLoc();
so, it assumes that the default locale was en_US. Observe for example this in
the DefaultLocale.java:
// used in urlLocale test
public static void checkRDefaultLocale() throws SQLException
{
System.out.println(savedLocale);
if (!savedLocale.equals(en_US))
throw new SQLException(wrong_locale);
}
--
Now, whether this is a reasonable assumption is a different question...
So far, the only way I have found of ensuring that the test runs with default
locale set to en_US is by hacking into the test harness' jvm.java and forcing
user.country to US and user.language to en.
Is that an acceptable thing to do?
I will experiment some more with different ways of setting this parameter.
Myrna
i18n/urlLocale.sql test fails on Windows XP
---
Key: DERBY-834
URL: http://issues.apache.org/jira/browse/DERBY-834
Project: Derby
Type: Bug
Components: Test
Environment: CYGWIN
NT-5.2
i686-unknown
Sun JDK 1.5 VM
Reporter: David Van Couvering
See
http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/370210-i18nTest_diff.txt
This failure has been around since forever, I went all the way back to
revision 295051 in October 2005 and it was there.
I don't see this test on my platform (XP, JDK 1.4, en_US locale), maybe it's
a Norwegian thing :)
--
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
Global Jira filters for regression test failures and patch available?
Would it make sense to have global Jira filters for: - Derby regression test failures unresolved Regression Test Failure issues - Derby patches available unresolved patch available issues ? Is there anyway to have a direct link to one of the global filters? I remember playing with it a while back for Derby open code bugs, but not being able to find a way. Thanks Kathey
[jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network config
[ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12367255 ] Satheesh Bandaram commented on DERBY-464: - Dan asked: Another quote from the spec quote A table may only be created or dropped by the owner of the table's schema. Table creation permission is notgrantable. (This is the SQL2003 spec) /quote Is there a reference, page number section number, for the comment about the SQL2003 spec? This is the best reference I can find in SQL 2003 spec. It is indirectly implied says persistent objects described by the (schema) descriptors are said to be owned by or to have been created by the authorizationID of the schema. Also, I couldn't find a privilege that can be granted to create tables. 4.20 SQL-schemas An SQL-schema is a persistent descriptor that includes: — The name of the SQL-schema. — The authorization identifier of the owner of the SQL-schema. ... In this part of ISO/IEC 9075, the term schema is used only in the sense of SQL-schema. The persistent objects described by the descriptors are said to be owned by or to have been created by the authorization identifier of the schema. Each component descriptor is one of: — A domain descriptor. — A base table descriptor. — A view descriptor. — A constraint descriptor. Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations. --- Key: DERBY-464 URL: http://issues.apache.org/jira/browse/DERBY-464 Project: Derby Type: New Feature Components: SQL Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Attachments: GrantRevokePartII.txt, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5, grantRevokeSpec.html Derby currently provides a very simple permissions scheme, which is quite suitable for an embedded database system. End users of embedded Derby do not see Derby directly; they talk to a application that embeds Derby. So Derby left most of the access control work to the application. Under this scheme, Derby limits access on a per database or per system basis. A user can be granted full, read-only, or no access. This is less suitable in a general purpose SQL server. When end users or diverse applications can issue SQL commands directly against the database, Derby must provide more precise mechanisms to limit who can do what with the database. I propose to enhance Derby by implementing a subset of grant/revoke capabilities as specified by the SQL standard. I envision this work to involve the following tasks, at least: 1) Develop a specification of what capabilities I would like to add to Derby. 2) Provide a high level implementation scheme. 3) Pursue a staged development plan, with support for DDL added to Derby first. 4) Add support for runtime checking of these privileges. 5) Address migration and upgrade issues from previous releases and from old scheme to newer database. Since I think this is a large task, I would like to invite any interested people to work with me on this large and important enhancement to Derby. -- 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-1020) Network Server treats errors on cleanup of connections as an unexpected error after intentional shutdown of the database/server
Network Server treats errors on cleanup of connections as an unexpected error after intentional shutdown of the database/server --- Key: DERBY-1020 URL: http://issues.apache.org/jira/browse/DERBY-1020 Project: Derby Type: Bug Components: Network Server Versions: 10.2.0.0, 10.1.3.0, 10.1.2.3, 10.3.0.0 Reporter: Kathey Marsden Priority: Minor Any exceptions that occur in the rollback and close of connections in Session.close() are treated as unexpected errors and print to the console. Exceptions that occur cleaning up the connection after intentional shutdown are not really unexpected. The console message can be disconcerting and intermittent as it depends on time. It is the root cause of DERBY-273 and I believe DERBY-803 -- 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-803) derbynet/DerbyNetAutoStart.java test fails intermittently with org.apache.derby.iapi.services.context.ShutdownException
[ http://issues.apache.org/jira/browse/DERBY-803?page=all ] Kathey Marsden updated DERBY-803: - Component: Regression Test Failure Description: DerbyNetAutoStart fails intermittently with the following diff: This issue is likely related to DERBY-1020 * Diff file derbyall/derbynetmats/DerbyNet/derbynetmats/DerbyNetAutoStart.diff *** Start: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats 2006-01-05 23:39:40 *** 1a2,3 org.apache.derby.iapi.services.context.ShutdownException: at org.apache.derby.impl.drda.Session.close(Unknown Source)agentThread[DRDAConnThread_3,5,derby.daemons] Test Failed. *** End: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats 2006-01-05 23:41:10 *** was: DerbyNetAutoStart fails intermittently with the following diff: I believe that this is in fact the same issue as DERBY-273, but am filing a separate issue, just in case that is not the case. * Diff file derbyall/derbynetmats/DerbyNet/derbynetmats/DerbyNetAutoStart.diff *** Start: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats 2006-01-05 23:39:40 *** 1a2,3 org.apache.derby.iapi.services.context.ShutdownException: at org.apache.derby.impl.drda.Session.close(Unknown Source)agentThread[DRDAConnThread_3,5,derby.daemons] Test Failed. *** End: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats 2006-01-05 23:41:10 *** derbynet/DerbyNetAutoStart.java test fails intermittently with org.apache.derby.iapi.services.context.ShutdownException --- Key: DERBY-803 URL: http://issues.apache.org/jira/browse/DERBY-803 Project: Derby Type: Test Components: Network Server, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden DerbyNetAutoStart fails intermittently with the following diff: This issue is likely related to DERBY-1020 * Diff file derbyall/derbynetmats/DerbyNet/derbynetmats/DerbyNetAutoStart.diff *** Start: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats 2006-01-05 23:39:40 *** 1a2,3 org.apache.derby.iapi.services.context.ShutdownException: at org.apache.derby.impl.drda.Session.close(Unknown Source)agentThread[DRDAConnThread_3,5,derby.daemons] Test Failed. *** End: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats 2006-01-05 23:41:10 *** -- 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-834) i18n/urlLocale.sql test fails on Windows XP
[ http://issues.apache.org/jira/browse/DERBY-834?page=all ] Myrna van Lunteren updated DERBY-834: - Comment: was deleted i18n/urlLocale.sql test fails on Windows XP --- Key: DERBY-834 URL: http://issues.apache.org/jira/browse/DERBY-834 Project: Derby Type: Bug Components: Test Environment: CYGWIN NT-5.2 i686-unknown Sun JDK 1.5 VM Reporter: David Van Couvering See http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/370210-i18nTest_diff.txt This failure has been around since forever, I went all the way back to revision 295051 in October 2005 and it was there. I don't see this test on my platform (XP, JDK 1.4, en_US locale), maybe it's a Norwegian thing :) -- 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-479) Passing the return of a RETURN NULL ON NULL INPUT function to another function call throws linkage error.
[ http://issues.apache.org/jira/browse/DERBY-479?page=comments#action_12367261 ] Daniel John Debrunner commented on DERBY-479: - The comment you added/modified in MethodCallNode is: + ** If the parameter is a SQL ValueNode, then put a + ** SQLToJavaValueNode on top of it. I see that as a comment that doesn't add any value, from the code I can see that is being done, the real value in a comment is explaining *why* something is done. Looking more at StaticMethodCallNode.optimizeDomainValueConversion() I'm not convinced it is correct. The comments and code seem to say if I have f1(f2()) then if f2() is CALLED ON NULL INPUT then I can take the java value directly from f2() and pass it to f1(). But, what if f1() is RETURNS NULL ON NULL INPUT, don't I need the SQL nodes to perform the NULL check? Thus don't both methods, the one being called and the one providing the parameter have to be CALLED ON NULL INPUT to take allow the conversion nodes to be dropped? In the optimizeDomainValueConversion I think you need to check for the node being an instance of StaticMethodCallNode and not MethodCallNode, and I think for routine being null. StaticMethodCallNode and MethodCallNode are stil used for internal SQL that uses Java expressions directly and are not defined SQL routines. Another aspect that may not be important, but before this change the conversion nodes are always dropped if they are between Java expressions, and that was incorrect in one situation, functions with RETURNS NULL ON NULL INPUT. Now you have changed it so they are only dropped in one situation, both methods being CALLED ON NULL INPUT (assuming a modified patch). Thus the optimization is being lost in situations where it is useful. Maybe this is not an issue because those siutations typically don't arise any more, but some internal statements that use Java expressions may be losing this optimization. Passing the return of a RETURN NULL ON NULL INPUT function to another function call throws linkage error. -- Key: DERBY-479 URL: http://issues.apache.org/jira/browse/DERBY-479 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assignee: Mamta A. Satoor Attachments: Derby479LinkageErrorReturnNullIfNulldiff021306.txt, Derby479LinkageErrorReturnNullIfNulldiff021406.txt, Derby479LinkageErrorReturnNullIfNulldiff021606.txt, Derby479Version4LinkageErrorReturnNullIfNull022006.txt, wisconsin.out, wisconsinAfterRemovingNullChk.out Error in ij (RN_RADIANS is a function declared as returns null on null input) ij VALUES CAST( CALL_COS(RN_RADIANS(90.0)) AS DECIMAL(3,2)); ERROR XBCM1: Java linkage error thrown during load of generated class org.apache.derby.exe.ace5214067x0105x5e41x7a46x855452e375. ERROR XJ001: Java exception: '(class: org/apache/derby/exe/ace5214067x0105x5e41x 7a46x855452e375, method: e0 signature: ()Ljava/lang/Object;) Expecting to find double on stack: java.lang.VerifyError'. extract from derby.log 2005-07-28 16:23:43.836 GMT Thread[main,5,main] Wrote class org.apache.derby.exe .ace5214067x0105x5e41x7a46x855452e375 to file C:\_work\svn_pb\trunk\systest\ out\functions\ace5214067x0105x5e41x7a46x855452e375.class. Please provide sup port with the file and the following exception information: java.lang.VerifyErro r: (class: org/apache/derby/exe/ace5214067x0105x5e41x7a46x855452e375, method : e0 signature: ()Ljava/lang/Object;) Expecting to find double on stack I will add a test case to lang/functions.sql commented with this bug number. Test cases that fail will be commented out. -- 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-834) i18n/urlLocale.sql test fails on Windows XP
[
http://issues.apache.org/jira/browse/DERBY-834?page=comments#action_12367263 ]
Myrna van Lunteren commented on DERBY-834:
--
This behavior is to be expected when the test is run on a machine that does not
have the en_US locale set.
observe this in the .sql:
---
create procedure checkDatabaseLoc(in locale char(12)) parameter style java
language java external name
'org.apache.derbyTesting.functionTests.tests.i18n.DefaultLocale.checkDatabaseLocale';
create procedure checkRDefaultLoc() parameter style java language java external
name
'org.apache.derbyTesting.functionTests.tests.i18n.DefaultLocale.checkRDefaultLocale';
-- this current database was created with the default locale
call checkDatabaseLoc('en_US');
call checkRDefaultLoc();
so, it assumes that the default locale was en_US.
Observe also for example this in the DefaultLocale.java:
// used in urlLocale test
public static void checkRDefaultLocale() throws SQLException
{
System.out.println(savedLocale);
if (!savedLocale.equals(en_US))
throw new SQLException(wrong_locale);
}
--
Now, whether this is a reasonable assumption is a different question...
So far, the only way I have found of ensuring that the test runs with default
locale set to en_US is by hacking into the test harness' jvm.java and forcing
user.country to US and user.language to en.
Is that an acceptable thing to do?
I will experiment some more with different ways of setting this parameter.
Myrna
i18n/urlLocale.sql test fails on Windows XP
---
Key: DERBY-834
URL: http://issues.apache.org/jira/browse/DERBY-834
Project: Derby
Type: Bug
Components: Test
Environment: CYGWIN
NT-5.2
i686-unknown
Sun JDK 1.5 VM
Reporter: David Van Couvering
See
http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/370210-i18nTest_diff.txt
This failure has been around since forever, I went all the way back to
revision 295051 in October 2005 and it was there.
I don't see this test on my platform (XP, JDK 1.4, en_US locale), maybe it's
a Norwegian thing :)
--
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
Re: Performance regressions
Mike Matrigali [EMAIL PROTECTED] wrote: ok, I was hoping that for single user testing it wouldn't be a big change. The single user commit per update is a problem when comparing derby to other db's which don't do real transaction guarantees. It would be great if someone reading the derby web site would pick the 1000 row per commit single user case to look at first. I agree that for the single user testing it should not be a big change. I might give it a try and see what results I get. I just looked at the insert case, and on the following page it looks to me like the single user case is taking about 6% user time and 2% system time. Am I reading the %cpu graph correctly? From the description I think this is a 2 processor machine. With 2 processors will it be possible to register 200% of cpu or just 100% of cpu (I have seen both possibilities on multiprocessor machines depending on the tool). You are right about the interpretation of the CPU graphs, the second CPU graph shows the amount of CPU that the java process (client code and Derby embedded) uses in user and system time. It is a 2 CPU machine, and in CPU scale goes to 100%. What surprices me a bit when looking at the CPU graph is that in the single user case even with the write cache on the disks enabled we are only able utilize about 6-7 percent of the CPU. I will look into it, but I guess it is the disk where the log is written that limits the throughput. ..olav Olav Sandstaa wrote: Mike Matrigali [EMAIL PROTECTED] wrote: Thanks for the info, anything is better than nothing. Any chance to measure something like 1000 records per commit. With one record per commit for the update operations you are not really measuring the work to do the operation just the overhead of commit -- at least for the single user case -- assuming your machine is set up to let derby do real disk syncs (no write cache enabled). The write cache on the disks are enabled in order make this test CPU bound also for insert, update and delete load instead of disk bound. I agree that only having one insert/update/delete operation per transaction/commit we include a lot of overhead for the commit. The intention is not to measure throughput, but to identify regressions and even if the commit takes 50 percent (just guessing) of the CPU cost/work of doing an update transaction it should still be possible to identify if there are changes in the update operation itself that influence on the CPU usage/throughput. Unfortunately I will have to make major changes to the test client if it should do 1000 updates per commit. All clients work on the same table and perform the operation on a random record. With multiple updates per transaction it would lead to a lot of deadlocks. I think it would be better to write a new load client than to try to tweek the one I run right now. I am also running some tests where the write cache on the disks are disabled (as it should be), but I have not included the results on the web page yet (mostly due to much higher variation in the test results). ..olav
Regression Test Failure! - TinderBox_Derby 379532 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 379532/2006-02-21 18:02:33 CET *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 7637630 099.47% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-379532.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/379532.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/379532.txt (All results in http://www.multinet.no/~solberg/public/Apache/index.html)
Re: Global Jira filters for regression test failures and patch available?
I have created a global filter, Derby: Regression Test Failures. It currently shows three rows. http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310744 Key Summary Assignee Reporter Pr Status Res Created Updated Bugzilla Id DERBY-956 OutOfMemoryError: Java heap space in stress.multi Unassigned Ole Solberg Open UNRESOLVED 11/Feb/06 14/Feb/06 DERBY-800 derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout ystein Grvlen Kathey Marsden In Progress UNRESOLVED 07/Jan/06 21/Feb/06 DERBY-654 unit/T_RawStoreFactory.unit fails with an assert failure in J2ME/CDC/FP Unassigned Deepa Remesh Open UNRESOLVED 27/Oct/05 23/ You should be able to find the link from Derby's JIRA page, under 'Filters'. Satheesh Kathey Marsden wrote: Would it make sense to have global Jira filters for: - Derby regression test failures unresolved "Regression Test Failure" issues - Derby patches available unresolved patch available issues ? Is there anyway to have a direct link to one of the global filters? I remember playing with it a while back for Derby open code bugs, but not being able to find a way. Thanks Kathey
Re: Performance regressions
Olav.Sandstaa wrote: Mike Matrigali [EMAIL PROTECTED] wrote: ok, I was hoping that for single user testing it wouldn't be a big change. The single user commit per update is a problem when comparing derby to other db's which don't do real transaction guarantees. It would be great if someone reading the derby web site would pick the 1000 row per commit single user case to look at first. I agree that for the single user testing it should not be a big change. I might give it a try and see what results I get. I just looked at the insert case, and on the following page it looks to me like the single user case is taking about 6% user time and 2% system time. Am I reading the %cpu graph correctly? From the description I think this is a 2 processor machine. With 2 processors will it be possible to register 200% of cpu or just 100% of cpu (I have seen both possibilities on multiprocessor machines depending on the tool). You are right about the interpretation of the CPU graphs, the second CPU graph shows the amount of CPU that the java process (client code and Derby embedded) uses in user and system time. It is a 2 CPU machine, and in CPU scale goes to 100%. What surprices me a bit when looking at the CPU graph is that in the single user case even with the write cache on the disks enabled we are only able utilize about 6-7 percent of the CPU. I will look into it, but I guess it is the disk where the log is written that limits the throughput. Yes these numbers look exactly like what I would expect from a log disk that is doing real sync per commit on a test that does a single row per commit. Usually for insert tests the db cache does a pretty good job, so the only real I/O load is the log disk (this is data specific as one can pick a large data size with indexes and careful worst case data distribution of insert data that forces a database I/O per insert). Real thoughput increases an order of magnitude when inserts are batched in my experience if the log disk is doing real syncs. It is of course hardware/OS specific, but usually the log writes are so clustered that write cache is a big win in this case, at least that is what we see on windows. ..olav Olav Sandstaa wrote: Mike Matrigali [EMAIL PROTECTED] wrote: Thanks for the info, anything is better than nothing. Any chance to measure something like 1000 records per commit. With one record per commit for the update operations you are not really measuring the work to do the operation just the overhead of commit -- at least for the single user case -- assuming your machine is set up to let derby do real disk syncs (no write cache enabled). The write cache on the disks are enabled in order make this test CPU bound also for insert, update and delete load instead of disk bound. I agree that only having one insert/update/delete operation per transaction/commit we include a lot of overhead for the commit. The intention is not to measure throughput, but to identify regressions and even if the commit takes 50 percent (just guessing) of the CPU cost/work of doing an update transaction it should still be possible to identify if there are changes in the update operation itself that influence on the CPU usage/throughput. Unfortunately I will have to make major changes to the test client if it should do 1000 updates per commit. All clients work on the same table and perform the operation on a random record. With multiple updates per transaction it would lead to a lot of deadlocks. I think it would be better to write a new load client than to try to tweek the one I run right now. I am also running some tests where the write cache on the disks are disabled (as it should be), but I have not included the results on the web page yet (mostly due to much higher variation in the test results). ..olav
Re: Performance regressions
For multi user tests I would not worry about batching the tests as much. It would be better if we can demonstrate that as more users are added throughput increases. If we are using 6% of the cpu I could see it taking more than 17 threads running unblocks to drive the group commit log fast enough to use up all the cpu. Olav.Sandstaa wrote: Mike Matrigali [EMAIL PROTECTED] wrote: ok, I was hoping that for single user testing it wouldn't be a big change. The single user commit per update is a problem when comparing derby to other db's which don't do real transaction guarantees. It would be great if someone reading the derby web site would pick the 1000 row per commit single user case to look at first. I agree that for the single user testing it should not be a big change. I might give it a try and see what results I get. I just looked at the insert case, and on the following page it looks to me like the single user case is taking about 6% user time and 2% system time. Am I reading the %cpu graph correctly? From the description I think this is a 2 processor machine. With 2 processors will it be possible to register 200% of cpu or just 100% of cpu (I have seen both possibilities on multiprocessor machines depending on the tool). You are right about the interpretation of the CPU graphs, the second CPU graph shows the amount of CPU that the java process (client code and Derby embedded) uses in user and system time. It is a 2 CPU machine, and in CPU scale goes to 100%. What surprices me a bit when looking at the CPU graph is that in the single user case even with the write cache on the disks enabled we are only able utilize about 6-7 percent of the CPU. I will look into it, but I guess it is the disk where the log is written that limits the throughput. ..olav Olav Sandstaa wrote: Mike Matrigali [EMAIL PROTECTED] wrote: Thanks for the info, anything is better than nothing. Any chance to measure something like 1000 records per commit. With one record per commit for the update operations you are not really measuring the work to do the operation just the overhead of commit -- at least for the single user case -- assuming your machine is set up to let derby do real disk syncs (no write cache enabled). The write cache on the disks are enabled in order make this test CPU bound also for insert, update and delete load instead of disk bound. I agree that only having one insert/update/delete operation per transaction/commit we include a lot of overhead for the commit. The intention is not to measure throughput, but to identify regressions and even if the commit takes 50 percent (just guessing) of the CPU cost/work of doing an update transaction it should still be possible to identify if there are changes in the update operation itself that influence on the CPU usage/throughput. Unfortunately I will have to make major changes to the test client if it should do 1000 updates per commit. All clients work on the same table and perform the operation on a random record. With multiple updates per transaction it would lead to a lot of deadlocks. I think it would be better to write a new load client than to try to tweek the one I run right now. I am also running some tests where the write cache on the disks are disabled (as it should be), but I have not included the results on the web page yet (mostly due to much higher variation in the test results). ..olav
Re: Grant/Revoke subtask - EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER
Thanks for picking this up. A sub-task under DERBY-464 sounds good. Satheesh Mamta Satoor wrote: Hi, Satheesh has added the parser support for EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER on a routine (function or procedure). eg from lang/grantRevoke.sql test CREATE PROCEDURE AUTH_TEST.addUserUtility(IN userName VARCHAR(50), IN permission VARCHAR(22)) LANGUAGE JAVA PARAMETER STYLE JAVA EXTERNAL SECURITY INVOKER EXTERNAL NAME 'org.apache.derby.database.UserUtility.add '; But this information about INVOKER vs DEFINER doesn't get stored in any system table. I am looking into finishing up this subtask to see what may be required during compile, execute and upgrade times for this subtask. Will send more information as I make more progress. thanks, Mamta ps Will it be useful to create a subtask of Derby-464 to keep track of this work?
[jira] Created: (DERBY-1021) Perform cleanup actions which require synchronization outside the finalizer
Perform cleanup actions which require synchronization outside the finalizer --- Key: DERBY-1021 URL: http://issues.apache.org/jira/browse/DERBY-1021 Project: Derby Type: Bug Components: Network Client Environment: Derby Network Client Driver Reporter: Deepa Remesh In client driver, finalize() method in Statement class involves synchronized calls. This may block the finalizer thread and potentially the JVM. In general, avoid any synchronized operation from finalizer. Embedded driver performs the cleanup actions outside the finalizer. See EmbedPreparedStatement.finalize. A similar mechanism needs to be used in client driver. The existing code in client's finalize() methods do not cause any problems so far because finalize was getting called only after explicit close of statement objects. So the code in the finalizer does not get exercised. Once the memory leaks are removed as part of DERBY-210 (https://issues.apache.org/jira/browse/DERBY-210), the finalizer can get called as soon as the application dereferences a statement object. To be able to proceed with DERBY-210, patch4 in DERBY-210 changes the finalizer method to not do any synchronized actions. It removes sending of any network messages from finalizer: 1) Removes sending commit messages to network server 2) Removes sending CLSQRY to cleanup all result sets of a statement on network server since the cleanup of result sets on network server will happen when a statement is re-used. Kathey pointed out some scenarios and said that we still need to do 2) - we need to send CLSQRY for all result sets of a statement when the statement is finalized. Sending CLSQRY command needs to be synchronized. Hence, we need to implement a mechanism similar to what is done in embedded driver finalizers. -- 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-965) DatabaseMetadata method supportsResultSetConcurrency returns wrong result on network client
[ http://issues.apache.org/jira/browse/DERBY-965?page=all ] Dag H. Wanvik reassigned DERBY-965: --- Assign To: Dag H. Wanvik DatabaseMetadata method supportsResultSetConcurrency returns wrong result on network client --- Key: DERBY-965 URL: http://issues.apache.org/jira/browse/DERBY-965 Project: Derby Type: Bug Components: Network Server, Network Client Versions: 10.2.0.0 Environment: Solaris 10, x86, Sun JDK 1.4.2 Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Priority: Minor Attachments: Main.java The DatabaseMetaData method supportsResultSetConcurrency erroneously returns false on the network client for all arguments combination, cf the attached repro program. The embedded client returns correct results, viz the output: org.apache.derby.jdbc.ClientDriver: SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: false SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: false SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: false org.apache.derby.jdbc.EmbeddedDriver: SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: true SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: true SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: true SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: false SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: false Presumably, this is wrong in released versions as well. -- 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-1022) syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128)
syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128) - Key: DERBY-1022 URL: http://issues.apache.org/jira/browse/DERBY-1022 Project: Derby Type: Bug Components: Regression Test Failure Reporter: Daniel John Debrunner Partial diff *** Start: syscat jdk1.4.2 DerbyNetClient derbynetmats:derbynetmats 2006-02-21 1 4:01:08 *** 157 del SYSCOLPERMS |GRANTEE |1 |VARCHAR(30) NOT NULL 158 del SYSCOLPERMS |GRANTOR |2 |VARCHAR(30) NOT NULL 158a157,158 SYSCOLPERMS |GRANTEE |1 |VARCHAR(128) NOT NULL SYSCOLPERMS |GRANTOR |2 |VARCHAR(128) NOT NULL -- 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-1006) Client allows setHoldability to HOLD_CURSORS_OVER_COMMIT on both connection and statement in a global transaction
[ http://issues.apache.org/jira/browse/DERBY-1006?page=all ]
Daniel John Debrunner reassigned DERBY-1006:
Assign To: Daniel John Debrunner
Client allows setHoldability to HOLD_CURSORS_OVER_COMMIT on both connection
and statement in a global transaction
--
Key: DERBY-1006
URL: http://issues.apache.org/jira/browse/DERBY-1006
Project: Derby
Type: Bug
Versions: 10.1.2.2, 10.3.0.0
Reporter: Kathey Marsden
Assignee: Daniel John Debrunner
Client allows holdability to be set to HOLD_CURSORS_OVER_COMMIT in a global
transaction.
I am not sure of the impact on the server side.
To reproduce look for this code in checkDataSource30 and take out the return
for client.
if (!TestUtil.isEmbeddedFramework())
{
// Don't run the rest of the test for client
// Network XA BUG: Client allows set
HOLD_CURSORS_OVER_COMMIT
// to be set in a a global transaction on the
connection and
// statements
conn.close();
return;
}
xid = getXid(24, (byte) 21, (byte) 01);
xr.start(xid, XAResource.TMNOFLAGS);
System.out.println(CONNECTION(xa) HOLDABILITY +
(conn.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT));
try {
conn.setHoldability(ResultSet.HOLD_CURSORS_OVER_COMMIT);
System.out.println(FAIL allowed to set hold
mode in xa transaction);
} catch (SQLException sqle) {
System.out.println(Expected
SQLException(setHoldability) + sqle.getMessage());
}
--
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
Re: Global Jira filters for regression test failures and patch available?
Myrna van Lunteren wrote: Hi, that link gave me an error (and subsequently my windoze OS got a page fault :-/ ) I couldn't find it under filters, do I need special permission to access that filter? But I'm wondering what you have in there, because e.g. DERBY-988 should show up for Regression tests. I think the filter needs to grab items from both type 'Bug' and type 'Test', does it do that? Myrna Hi, I can't find the filter either. But JIRA is acting strange on me again... Alsa, like Myrna, I'm missing an issue; DERBY-788. Type: Bug. Components: Services, Test, Regression Test Failure. Does the filter handle multiple components? -- Kristian On 2/21/06, *Satheesh Bandaram* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have created a global filter, *Derby: Regression Test Failures*. It currently shows three rows. http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310744 http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12310744 *Key* [Descending order - Click to sort in ascending order] *Summary* *Assignee* *Reporter* *Pr**Status**Res* *Created* *Updated* *Bugzilla Id* Bug http://issues.apache.org/jira/browse/DERBY-956 DERBY-956 http://issues.apache.org/jira/browse/DERBY-956 OutOfMemoryError: Java heap space in stress.multi http://issues.apache.org/jira/browse/DERBY-956 Unassigned Ole Solberg Blocker Open Open UNRESOLVED 11/Feb/06 14/Feb/06 Bug http://issues.apache.org/jira/browse/DERBY-800 DERBY-800 http://issues.apache.org/jira/browse/DERBY-800 derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout http://issues.apache.org/jira/browse/DERBY-800 Øystein Grøvlen Kathey Marsden CriticalIn Progress In Progress UNRESOLVED 07/Jan/06 21/Feb/06 Bug http://issues.apache.org/jira/browse/DERBY-654 DERBY-654 http://issues.apache.org/jira/browse/DERBY-654 unit/T_RawStoreFactory.unit fails with an assert failure in J2ME/CDC/FP http://issues.apache.org/jira/browse/DERBY-654 Unassigned Deepa RemeshMinor Open Open UNRESOLVED 27/Oct/05 23/ You should be able to find the link from Derby's JIRA page, under 'Filters'. Satheesh Kathey Marsden wrote: Would it make sense to have global Jira filters for: - Derby regression test failures unresolved Regression Test Failure issues - Derby patches available unresolved patch available issues ? Is there anyway to have a direct link to one of the global filters? I remember playing with it a while back for Derby open code bugs, but not being able to find a way. Thanks Kathey
[jira] Updated: (DERBY-805) Push join predicates into union and other set operations. DERBY-649 implemented scalar (single table) predicate pushdown. Adding join predicate push down could improve perf
[ http://issues.apache.org/jira/browse/DERBY-805?page=all ] A B updated DERBY-805: -- Other Info: (was: [Patch available]) While working with other changes for this issue, I came to realize that d805_phase1_v2 has one small problem. That patch assumes that an OptimizerImpl will always find a best join order before it attempts to pull any Optimizables and re-position them for another join order. But with the JUMPING functionality that the Optimizer does for queries with a large number of tables, it turns out that it is in fact possible to pull an Optimizable before finding a best join order. So I need to update the Phase 1 patch to account for this. I already have the required fixes locally; I want to run derbylang to make sure nothing breaks, and then I will post another version of the patch. In the meantime, I'm unchecking the patch available box... Push join predicates into union and other set operations. DERBY-649 implemented scalar (single table) predicate pushdown. Adding join predicate push down could improve performance significantly. -- Key: DERBY-805 URL: http://issues.apache.org/jira/browse/DERBY-805 Project: Derby Type: Sub-task Components: SQL Versions: 10.1.2.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: A B Fix For: 10.2.0.0 Attachments: DERBY-805.html, DERBY-805_v2.html, d805_phase1_v1.patch, d805_phase1_v1.stat, d805_phase1_v2.patch, d805_phase1_v2.stat Fix for DERBY-649 implemented scalar (single table) predicate push down into UNIONs. While this improves performance for one set of queries, ability to push join-predicates further improves Derby performance by enabling use of indices where possible. For example, create view V1 as select i, j from T1 union all select i,j from T2; create view V2 as select a,b from T3 union all select a,b from T4; insert into T1 values (1,1), (2,2), (3,3), (4,4), (5,5); For a query like select * from V1, V2 where V1.j = V2.b and V1.i =1; If the join order choosen is V1,V2, V1 can use index on V1.i (if present) following fix for DERBY-649. But if there is a index on V2.b also, Derby currently can't use that index. By pushing join predicate, Derby would be able to use the index and improve performance. Some of the queries I have seen (not the one shown here...) could improve from 70-120 seconds to about one second. Note there is a good comment by Jeff Lichtman about join-predicate push down. I am copying parts of it here for completeness of this report: (Modified) If predicate push down is done during optimization, it would be possible to push joins into the union as long as it's in the right place in the join order. For example: create view v as select * from t1 union all select * from t2; select * from v, t3 where v.c1 = t3.c2; In this select, if t3 is the outer table then the qualification could be pushed into the union and optimized there, but if t3 is the inner table the qualification can't be pushed into the union. If the pushing is done at preprocess time (i.e. before optimization) it is impossible to know whether a join qualification like this can be safely pushed. There's a comment in UnionNode.optimizeIt() saying: /* RESOLVE - don't try to push predicated through for now */ This is where I'd expect to see something for pushing predicates into the union during optimization. BTW, the business of pushing and pulling predicates during optimization can be hard to understand and debug, so maybe it's best to only handle the simple cases and do it during preprocessing. -- 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
Re: Global Jira filters for regression test failures and patch available?
Kristian Waagan wrote: ... Hi, I can't find the filter either. But JIRA is acting strange on me again... Somebody reported Jira problems to infrastructure about 5 minutes ago. -jean
[jira] Updated: (DERBY-304) If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
[ http://issues.apache.org/jira/browse/DERBY-304?page=all ] Mike Matrigali updated DERBY-304: - Description: If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes! Repro: CallableStatement cs = conn.prepareCall(CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)); cs.setString(1, c:/maildb); cs.setInt(2, 1); cs.execute(); cs.close(); result: C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\. Until windows can not show the path!!! was: If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes! Repro: CallableStatement cs = conn.prepareCall(CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)); cs.setString(1, c:/maildb); cs.setInt(2, 1); cs.execute(); cs.close(); result: C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\. Until windows can not show the path!!! I reviewed, ran tests and committed this patch: m1_142:204svn commit Sendingjava\engine\org\apache\derby\iapi\services\io\FileUtil.java Sendingjava\engine\org\apache\derby\iapi\store\access\FileResource.java Sendingjava\engine\org\apache\derby\impl\sql\execute\JarDDL.java Sendingjava\engine\org\apache\derby\impl\store\raw\RawStore.java Sendingjava\engine\org\apache\derby\loc\messages_en.properties Sendingjava\shared\org\apache\derby\shared\common\reference\SQLState.jav a Adding java\testing\org\apache\derbyTesting\functionTests\master\BackupP athTests.out Sendingjava\testing\org\apache\derbyTesting\functionTests\suites\storemo re.runall Adding java\testing\org\apache\derbyTesting\functionTests\tests\store\Ba ckupPathTests.java Adding java\testing\org\apache\derbyTesting\functionTests\tests\store\Ba ckupPathTests_app.properties Sendingjava\testing\org\apache\derbyTesting\functionTests\tests\store\co pyfiles.ant Transmitting file data ... Committed revision 379620. If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes! --- Key: DERBY-304 URL: http://issues.apache.org/jira/browse/DERBY-304 Project: Derby Type: Bug Components: Store Versions: 10.1.1.0 Environment: With JDK 142 on Windows XP Reporter: Manjula Kutty Assignee: Suresh Thalamati Priority: Minor Attachments: derby-304.diff If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes! Repro: CallableStatement cs = conn.prepareCall(CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)); cs.setString(1, c:/maildb); cs.setInt(2, 1); cs.execute(); cs.close(); result: C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\. Until windows can not show the path!!! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1003) store/bootLock.java fails with J2ME/CDC/FP
[ http://issues.apache.org/jira/browse/DERBY-1003?page=all ] Mike Matrigali updated DERBY-1003: -- Component: Regression Test Failure store/bootLock.java fails with J2ME/CDC/FP -- Key: DERBY-1003 URL: http://issues.apache.org/jira/browse/DERBY-1003 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: IBM WCTME 5.7 j9_foundation Reporter: Deepa Remesh store/bootLock.java failed with j9_foundation VM in the weekend run. I ran this test few times on my machine and the test does not fail. Also, there was no exception in the weekend run failure. It seems like the second jvm which is started to boot Derby did not start in time. What test does: The test starts a second jvm (by calling store/bootLock1.java) which boots Derby. The test sleeps for some time waiting for the second jvm to start and boot Derby. Then it tries to boot Derby again and should get an expected exception for double-booting. From the failure, it seems like this second jvm did not start at all. I am guessing this could be a timing issue. I'll check if the test fails this weekend too. If anyone else sees this test fail with j9_foundation VM and has more information, please update this JIRA. -- 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-1023) Add EXTERNAL SECURITY DEFINER and EXTERNAL SECURITY INVOKER support for routines(functions or procedures)
Add EXTERNAL SECURITY DEFINER and EXTERNAL SECURITY INVOKER support for routines(functions or procedures) -- Key: DERBY-1023 URL: http://issues.apache.org/jira/browse/DERBY-1023 Project: Derby Type: Sub-task Components: SQL Reporter: Mamta A. Satoor Fix For: 10.2.0.0 Derby parser supports EXTERNAL SECURITY DEFINER and EXTERNAL SECURITY INVOKER on a routine (function or procedure) but this information doesn't get saved anywhere. eg from lang/grantRevoke.sql test CREATE PROCEDURE AUTH_TEST.addUserUtility(IN userName VARCHAR(50), IN permission VARCHAR(22)) LANGUAGE JAVA PARAMETER STYLE JAVA EXTERNAL SECURITY INVOKER EXTERNAL NAME 'org.apache.derby.database.UserUtility.add '; Finish up this functionality by doing necessary work required during compile, execute and upgrade times. -- 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-1023) Add EXTERNAL SECURITY DEFINER and EXTERNAL SECURITY INVOKER support for routines(functions or procedures)
[ http://issues.apache.org/jira/browse/DERBY-1023?page=all ] Mamta A. Satoor reassigned DERBY-1023: -- Assign To: Mamta A. Satoor Add EXTERNAL SECURITY DEFINER and EXTERNAL SECURITY INVOKER support for routines(functions or procedures) -- Key: DERBY-1023 URL: http://issues.apache.org/jira/browse/DERBY-1023 Project: Derby Type: Sub-task Components: SQL Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.2.0.0 Derby parser supports EXTERNAL SECURITY DEFINER and EXTERNAL SECURITY INVOKER on a routine (function or procedure) but this information doesn't get saved anywhere. eg from lang/grantRevoke.sql test CREATE PROCEDURE AUTH_TEST.addUserUtility(IN userName VARCHAR(50), IN permission VARCHAR(22)) LANGUAGE JAVA PARAMETER STYLE JAVA EXTERNAL SECURITY INVOKER EXTERNAL NAME 'org.apache.derby.database.UserUtility.add '; Finish up this functionality by doing necessary work required during compile, execute and upgrade times. -- 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-1013) jdbc4 test suite test classes are using Util.notImplemented
[ http://issues.apache.org/jira/browse/DERBY-1013?page=all ] Rick Hillegas resolved DERBY-1013: -- Resolution: Fixed Good step forward. Patch touches only jdbc 4 tests. They run cleanly. Committed with subversion revision 379634. jdbc4 test suite test classes are using Util.notImplemented --- Key: DERBY-1013 URL: http://issues.apache.org/jira/browse/DERBY-1013 Project: Derby Type: Bug Reporter: Anurag Shekhar Assignee: Anurag Shekhar Attachments: derby-1013.diff jdbc4 test suite test classes are using Util.notImplemented to get exception text and then using the message comparison to check if the message are same in the thrown exception. This may cause problem in future because the jdbc4 code is using SQLState.NOT_IMPLEMENTED with a paramter (feature name). As the test classes are creating the exception without any parameter the test comparision will fail. In this patch I have modified the test code to test for sql state which won't change. -- 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-1019) Add a main class to derbytools.jar so the tools can be run with java -jar
[ http://issues.apache.org/jira/browse/DERBY-1019?page=all ] Andrew McIntyre updated DERBY-1019: --- Attachment: toolsrun_v2.diff Hi Dan, thanks for the feedback. I agree that this should not be part of the public api. I've moved the run class into iapi and fixed the other issues noted as well. If there is no further feedback, I'll commit this patch. Add a main class to derbytools.jar so the tools can be run with java -jar - Key: DERBY-1019 URL: http://issues.apache.org/jira/browse/DERBY-1019 Project: Derby Type: Improvement Components: Tools Versions: 10.2.0.0, 10.1.3.0 Reporter: Andrew McIntyre Assignee: Andrew McIntyre Fix For: 10.2.0.0 Attachments: toolsrun.diff, toolsrun.stat, toolsrun_v2.diff Add a class to derbytools.jar as it's default run class that just switches on the available tools, so a user can run: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook -- 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-1019) Add a main class to derbytools.jar so the tools can be run with java -jar
[ http://issues.apache.org/jira/browse/DERBY-1019?page=all ] Andrew McIntyre updated DERBY-1019: --- Attachment: (was: toolsrun_v2.diff) Add a main class to derbytools.jar so the tools can be run with java -jar - Key: DERBY-1019 URL: http://issues.apache.org/jira/browse/DERBY-1019 Project: Derby Type: Improvement Components: Tools Versions: 10.2.0.0, 10.1.3.0 Reporter: Andrew McIntyre Assignee: Andrew McIntyre Fix For: 10.2.0.0 Attachments: toolsrun.diff, toolsrun.stat Add a class to derbytools.jar as it's default run class that just switches on the available tools, so a user can run: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook -- 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-1019) Add a main class to derbytools.jar so the tools can be run with java -jar
[ http://issues.apache.org/jira/browse/DERBY-1019?page=all ] Andrew McIntyre updated DERBY-1019: --- Attachment: toolsrun_v2.diff Add a main class to derbytools.jar so the tools can be run with java -jar - Key: DERBY-1019 URL: http://issues.apache.org/jira/browse/DERBY-1019 Project: Derby Type: Improvement Components: Tools Versions: 10.2.0.0, 10.1.3.0 Reporter: Andrew McIntyre Assignee: Andrew McIntyre Fix For: 10.2.0.0 Attachments: toolsrun.diff, toolsrun.stat, toolsrun_v2.diff Add a class to derbytools.jar as it's default run class that just switches on the available tools, so a user can run: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook -- 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-903) Remove use of String(byte[]) and String(byte[], int, int) constructors in testing leading to non-portable behaviour
[ http://issues.apache.org/jira/browse/DERBY-903?page=all ] Andrew McIntyre resolved DERBY-903: --- Resolution: Fixed Committed followup patch with revision 379643. Remove use of String(byte[]) and String(byte[], int, int) constructors in testing leading to non-portable behaviour --- Key: DERBY-903 URL: http://issues.apache.org/jira/browse/DERBY-903 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assignee: Myrna van Lunteren Fix For: 10.2.0.0 Attachments: DERBY-903_021306.diff, DERBY-903_021306.stat, DERBY-903_followup1_2006_02_16.diff, DERBY-903_followup1_2006_02_16.stat These constructors use the Java default platform encoding to convert the bytes to a String, this typically leads to bugs on platforms with different encodings. Replace with code using fixed conversion, or alternative mechanisms. If the call is required its use should be commented as to why it is required. org.apache.derbyTesting.functionTests.tests.jdbcapi.blobclob4BLOB org.apache.derbyTesting.functionTests.tests.jdbcapi.resultset org.apache.derbyTesting.functionTests.tests.lang.coalesceTests org.apache.derbyTesting.functionTests.tests.store.streamingColumn I generated this list using the Java search in eclipse for references to the constructors String(byte[]) String(byte[],int,int) (no occurrences in java/testing) -- 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-1024) Client's XAResource.start throws XAException with XAER_RMFAIL when local transaction is active
Client's XAResource.start throws XAException with XAER_RMFAIL when local transaction is active -- Key: DERBY-1024 URL: http://issues.apache.org/jira/browse/DERBY-1024 Project: Derby Type: Bug Components: JDBC, Network Client Reporter: Daniel John Debrunner Priority: Minor perform some work in a local transaction without committing and then start a global transaction. Embedded throws an XAException with XAER_OUTSIDE - The resource manager is doing work outside a global transaction. Client throws an XAEception with XAER_RMFAIL - Resource manager is unavailable Seems like embedded has the correct error code, though I don't have the XA spec in front of me. -- 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
NetXAResource - duplicate constants?
Anyone have any idea why the client's NetXAResource has its own version of XA return value constants, that seem to have the same value as the constants in javax.transaction.xa.XAException? Thanks, Dan. org.apache.derby.client.net.NetXAResource // xaretval defines public static final int XARETVAL_XALCSNOTSUPP = 99; // Loosely Coupled Not Supported public static final int XARETVAL_RBROLLBACK = 100; // Rollback public static final int XARETVAL_RBCOMMFAIL = 101; // Rollback Communication Failure public static final int XARETVAL_RBDEADLOCK = 102; // Rollback Deadlock public static final int XARETVAL_RBINTEGRITY = 103; // Rollback integrity violation public static final int XARETVAL_RBOTHER = 104; // Rollback Other public static final int XARETVAL_RBPROTO = 105; // Rollback Protocol public static final int XARETVAL_RBTIMEOUT = 106; // Rollback Timeout public static final int XARETVAL_RBTRANSIENT = 107; // Rollback Transaction branch public static final int XARETVAL_NODISSOCIATE = 108; // Unable to Dissociate resources from connection public static final int XARETVAL_XATWOPHASE = 13; // TwoPhase commit required public static final int XARETVAL_XAPROMOTED = 12; // Promoted - unused public static final int XARETVAL_XADEFERRED = 11; // Deferred - unused public static final int XARETVAL_XACOMMFAIL = 10; // Communication Failure public static final int XARETVAL_XANOMIGRATE = 9; // No Migration public static final int XARETVAL_XAHEURHAZ = 8; // Heuristically completed public static final int XARETVAL_XAHEURCOM = 7; // Heuristically Commited public static final int XARETVAL_XAHEURRB = 6; // Heuristically Rolledback public static final int XARETVAL_XAHEURMIX = 5; // Branch heuristically commit and rollback public static final int XARETVAL_XARETRY = 4; // Retry Commit public static final int XARETVAL_XARDONLY = 3; // Read Only public static final int XARETVAL_XAOK = 0; // OK public static final int XARETVAL_XAERASYNC = -2; // Async Request not possible public static final int XARETVAL_XAERRMERR = -3; // RM Error public static final int XARETVAL_XAERNOTA = -4; // XID does not exist public static final int XARETVAL_XAERINVAL = -5; // Invalid arguments public static final int XARETVAL_XAERPROTO = -6; // Protocol Violation public static final int XARETVAL_XAERRMFAIL = -7; // RM Failed public static final int XARETVAL_XAERDUPID = -8; // Duplicate XID public static final int XARETVAL_XAEROUTSIDE = -9; // Local tansaction active public static final int XARETVAL_XAEROPENRES = -10; // Open resources
[jira] Closed: (DERBY-903) Remove use of String(byte[]) and String(byte[], int, int) constructors in testing leading to non-portable behaviour
[ http://issues.apache.org/jira/browse/DERBY-903?page=all ] Myrna van Lunteren closed DERBY-903: Remove use of String(byte[]) and String(byte[], int, int) constructors in testing leading to non-portable behaviour --- Key: DERBY-903 URL: http://issues.apache.org/jira/browse/DERBY-903 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assignee: Myrna van Lunteren Fix For: 10.2.0.0 Attachments: DERBY-903_021306.diff, DERBY-903_021306.stat, DERBY-903_followup1_2006_02_16.diff, DERBY-903_followup1_2006_02_16.stat These constructors use the Java default platform encoding to convert the bytes to a String, this typically leads to bugs on platforms with different encodings. Replace with code using fixed conversion, or alternative mechanisms. If the call is required its use should be commented as to why it is required. org.apache.derbyTesting.functionTests.tests.jdbcapi.blobclob4BLOB org.apache.derbyTesting.functionTests.tests.jdbcapi.resultset org.apache.derbyTesting.functionTests.tests.lang.coalesceTests org.apache.derbyTesting.functionTests.tests.store.streamingColumn I generated this list using the Java search in eclipse for references to the constructors String(byte[]) String(byte[],int,int) (no occurrences in java/testing) -- 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-1025) XAResource.start() does not commit an active local transaction when auto commit is true
XAResource.start() does not commit an active local transaction when auto commit is true --- Key: DERBY-1025 URL: http://issues.apache.org/jira/browse/DERBY-1025 Project: Derby Type: Bug Reporter: Daniel John Debrunner Embedded XAResource.start() implementation commits the active local transaction on the Connection associated with the XAResource if the connection is auto-commit mode. Client incorrectly throws an XAException with the XAER_RMFAIL error code (see DERBY-1024) XATest contains a work-around for client (calling commit) with a comment with this bug number. -- 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-575) test blobclob4BLOB fails on OS 390
[ http://issues.apache.org/jira/browse/DERBY-575?page=all ] Myrna van Lunteren resolved DERBY-575: -- Resolution: Fixed This has now been fixed with DERBY-903, revision 379643 test blobclob4BLOB fails on OS 390 -- Key: DERBY-575 URL: http://issues.apache.org/jira/browse/DERBY-575 Project: Derby Type: Bug Components: Test Versions: 10.1.1.0 Environment: OS/390 (z/OS 1.06; IBM j2RE 1.4.2) Reporter: Myrna van Lunteren Assignee: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 The subtest clobNegativeTest_Derby265 in test jdbcapi/blobclob4BLOB assumes that the length of the file used (aclob.txt) is 30 but on OS 390 (z/OS), after conversion to EBCDIC, the length is 297000. The test should be modified to not use a hardcoded size. -- 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
Regression Test Failure! - TinderBox_Derby 379593 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 379593/2006-02-21 22:32:49 CET *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 7637630 0 101.89% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-379593.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/379593.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/379593.txt (All results in http://www.multinet.no/~solberg/public/Apache/index.html)
Re: [jira] Created: (DERBY-1022) syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128)
Ouch... I will fix this. Satheesh Daniel John Debrunner (JIRA) wrote: syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128) - Key: DERBY-1022 URL: http://issues.apache.org/jira/browse/DERBY-1022 Project: Derby Type: Bug Components: Regression Test Failure Reporter: Daniel John Debrunner Partial diff *** Start: syscat jdk1.4.2 DerbyNetClient derbynetmats:derbynetmats 2006-02-21 1 4:01:08 *** 157 del SYSCOLPERMS |GRANTEE |1 |VARCHAR(30) NOT NULL 158 del SYSCOLPERMS |GRANTOR |2 |VARCHAR(30) NOT NULL 158a157,158 SYSCOLPERMS |GRANTEE |1 |VARCHAR(128) NOT NULL SYSCOLPERMS |GRANTOR |2 |VARCHAR(128) NOT NULL
Re: Global Jira filters for regression test failures and patch available?
Kristian Waagan wrote: Myrna van Lunteren wrote: Hi, that link gave me an error (and subsequently my windoze OS got a page fault :-/ ) I couldn't find it under filters, do I need special permission to access that filter? But I'm wondering what you have in there, because e.g. DERBY-988 should show up for Regression tests. I think the filter needs to grab items from both type 'Bug' and type 'Test', does it do that? Myrna Hi, I can't find the filter either. But JIRA is acting strange on me again... Alsa, like Myrna, I'm missing an issue; DERBY-788. Type: Bug. Components: Services, Test, Regression Test Failure. Does the filter handle multiple components? I needed to share the filter... It should show up now... Also, earlier I had the filter show only bugs marked for 10.2. I changed it now to show all open bugs. Now it shows 17 issues. There are so many unassigned Regression Test Failures... Should these be assigned to someone? Satheesh T Key Summary Assignee Reporter Pr Status Res Created Updated Bugzilla Id DERBY-1022 syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128) Unassigned Daniel John Debrunner Open UNRESOLVED 21/Feb/06 21/Feb/06 DERBY-1003 store/bootLock.java fails with J2ME/CDC/FP Unassigned Deepa Remesh Open UNRESOLVED 17/Feb/06 22/Feb/06 DERBY-989 unit/daemonService.unit fails intermittently: 'ran out of time' Unassigned Ole Solberg Open UNRESOLVED 15/Feb/06 15/Feb/06 DERBY-988 jdbcapi/parameterMapping.java fails on Win2003 with 'P3=SQLSTATE(22007): SQL Exception: The syntax of the string representation of a datetime value is incorrect.' Unassigned Ole Solberg Open UNRESOLVED 15/Feb/06 15/Feb/06 DERBY-980 derbynet/testSecMec.java fails with InterruptedException Unassigned Ole Solberg Open UNRESOLVED 14/Feb/06 15/Feb/06 DERBY-977 jdbcapi/xaSimplePositive.sql fails Unassigned Ole Solberg Open UNRESOLVED 14/Feb/06 16/Feb/06 DERBY-975 lang/updatableResultSet.java fails on ibm13 jvm. Fernanda Pizzorno Suresh Thalamati Open UNRESOLVED 14/Feb/06 20/Feb/06 DERBY-973 Restore fails in OnlineBackupTest1 Unassigned Ole Solberg Open UNRESOLVED 13/Feb/06 15/Feb/06 DERBY-967 lang/autoincrement.sql intermittently fails on SunOS-5.10_i86 Unassigned Ole Solberg Open UNRESOLVED 13/Feb/06 15/Feb/06 DERBY-957 Long passed into an exception gets displayed using locale specific formatting. i18n/locale issue Unassigned Ole Solberg Open UNRESOLVED 11/Feb/06 15/Feb/06 DERBY-956 OutOfMemoryError: Java heap space in stress.multi Unassigned Ole Solberg Open UNRESOLVED 11/Feb/06 14/Feb/06 DERBY-952 DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin Unassigned Ole Solberg Open UNRESOLVED 11/Feb/06 17/Feb/06 DERBY-803 derbynet/DerbyNetAutoStart.java test fails intermittently with org.apache.derby.iapi.services.context.ShutdownException Unassigned Kathey Marsden Open UNRESOLVED 09/Jan/06 21/Feb/06 DERBY-800 derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout ystein Grvlen Kathey Marsden In Progress UNRESOLVED
[jira] Assigned: (DERBY-1022) syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128)
[ http://issues.apache.org/jira/browse/DERBY-1022?page=all ] Satheesh Bandaram reassigned DERBY-1022: Assign To: Satheesh Bandaram syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128) - Key: DERBY-1022 URL: http://issues.apache.org/jira/browse/DERBY-1022 Project: Derby Type: Bug Components: Regression Test Failure Reporter: Daniel John Debrunner Assignee: Satheesh Bandaram Partial diff *** Start: syscat jdk1.4.2 DerbyNetClient derbynetmats:derbynetmats 2006-02-21 1 4:01:08 *** 157 del SYSCOLPERMS |GRANTEE |1 |VARCHAR(30) NOT NULL 158 del SYSCOLPERMS |GRANTOR |2 |VARCHAR(30) NOT NULL 158a157,158 SYSCOLPERMS |GRANTEE |1 |VARCHAR(128) NOT NULL SYSCOLPERMS |GRANTOR |2 |VARCHAR(128) NOT NULL -- 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-1026) LDAP with caching DNs in derby.user.userName as database property does not work
LDAP with caching DNs in derby.user.userName as database property does not work --- Key: DERBY-1026 URL: http://issues.apache.org/jira/browse/DERBY-1026 Project: Derby Type: Bug Components: Security Versions: 10.2.0.0, 10.1.2.2, 10.1.2.0, 10.1.2.1, 10.1.1.2, 10.1.1.0, 10.1.1.1, 10.0.2.1, 10.0.2.0 Reporter: Sunitha Kambhampati Priority: Minor The documentation talks about LDAP support with mapping user names to derby users using the derby.user.'userName' property. See links http://db.apache.org/derby/docs/dev/tuning/rtunproper37341.html http://db.apache.org/derby/docs/dev/tuning/rtunproper27355.html Per the documentation, one can use the derby.user property to set the DN for a user,and when using LDAP, setting the search filter to derby.user will pick up the DN from this property if available. This is not working when I tried it out by caching a user's dn as a database-level property. Found the following issues: 1)Setting the database property derby.user.userName to a DN does not work: Problem in AuthenticationServiceBase#map. -- If there is a system property derby.authentication.provider=LDAP, setting of derby.user.userName to a DN value as a database property will encrypt the DN value and store it. The code seems to expect that the derby.authentication.provider is set to LDAP as a database property, else it considers it as a password and encrypts the value. -- it doesnt return the correct mapped value for the property for the LDAP and derby.user.userName case. Returns null instead of returning the clear text DN value. 2) the LDAP code itself doesnt pick up the userDN. In LDAPAuthenticationSchemeImpl#authenticateUser if (useUserPropertyAsDN) userDN = authenticationService.getProperty( org.apache.derby.iapi.reference.Property.USER_PROPERTY_PREFIX) Here USER_PROPERTY_PREFIX is derby.user. The key should be USER_PROPERTY_PREFIX+userName. 3) After the code issues are fixed, it would be nice if documentation can be added to give a full example of how to go about doing LDAP authentication with caching DNs in derby.user. -- 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
Re: [jira] Created: (DERBY-1022) syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128)
Both are fixed now. Satheesh Myrna van Lunteren wrote: Satheesh, do you perhaps know anything about the failure in grantrevoke.sql also? From ole's mail: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/379593-derbyall_diff.txt Myrna On 2/21/06, Satheesh Bandaram [EMAIL PROTECTED] wrote: Ouch... I will fix this. Satheesh Daniel John Debrunner (JIRA) wrote: syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128) - Key: DERBY-1022 URL: http://issues.apache.org/jira/browse/DERBY-1022 Project: Derby Type: Bug Components: Regression Test Failure Reporter: Daniel John Debrunner Partial diff *** Start: syscat jdk1.4.2 DerbyNetClient derbynetmats:derbynetmats 2006-02-21 1 4:01:08 *** 157 del SYSCOLPERMS |GRANTEE |1 |VARCHAR(30) NOT NULL 158 del SYSCOLPERMS |GRANTOR |2 |VARCHAR(30) NOT NULL 158a157,158 SYSCOLPERMS |GRANTEE |1 |VARCHAR(128) NOT NULL SYSCOLPERMS |GRANTOR |2 |VARCHAR(128) NOT NULL
Re: Global Jira filters for regression test failures and patch available?
Try the filter now... Can you find it? Does it show right results? I had the filter show only issues marked for 10.2. Many don't have fix version. I think unassigned issues need to be assigned by finding the change that caused the failure (on standard platforms) or found a volunteer for non-standard platforms, if specific to that platform. Project: Derby Components: Regression Test Failure Status: Open, In Progress and Reopened Sorted by: Key descending Satheesh Myrna van Lunteren wrote: Hi, that link gave me an error (and subsequently my windoze OS got a page fault :-/ ) I couldn't find it under filters, do Ineed specialpermission to access that filter? But I'm wondering what you have in there, because e.g. DERBY-988 should show up for Regression tests. I think the filter needs to grab items from both type 'Bug' and type 'Test',does it do that? Myrna
Re: Grant -revoke (464) and future backwards compat
Francois Orsini wrote: I'll be posting more information soon. Great... Do you see this work going into 10.2 release or later versions? I would like to know so that documentation changes can be made appropriately for my work on Grant and Revoke. Satheesh
Re: Grant -revoke (464) and future backwards compat
Daniel John Debrunner wrote: I looked at some other databases (Oracle, DB2, Postgres) and the typical model is to require a database level privilege to create tables or call an external routine. Create table I could possibly go either way on, but if we followed the de-facto standard model of other databases then we need a database level privilege. Creating an external routine would have all sorts of security concerns for a database owner, it's allowing a remote user to execute code on their system. I will look into what other databases do and see if I can propose some additional changes... Satheesh
Regression Test Failure! - TinderBox_Derby 379648 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 379648/2006-02-22 03:02:47 CET *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 7638631 0 101.32% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-379648.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/379648.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/379648.txt (All results in http://www.multinet.no/~solberg/public/Apache/index.html)
