Nabble - Apache Derby Developers

[jira] Subscription: Derby: JIRA issues with patch available

2009-11-11T00:36:39Z

Issue Subscription
Filter: Derby: JIRA issues with patch available (12 issues)
Subscriber: derby-dev

Key Summary
DERBY-4102 Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K
https://issues.apache.org/jira/browse/DERBY-4102
DERBY-4432 Memory leak when attempting to boot non-existing database with the in-memory back end
https://issues.apache.org/jira/browse/DERBY-4432
DERBY-4436 Refactor existing in-memory back end tests and add new tests for dropping database
https://issues.apache.org/jira/browse/DERBY-4436
DERBY-4357 TableFunctions provide no information to limit underlying query
https://issues.apache.org/jira/browse/DERBY-4357
DERBY-4183 Our regression tests use various jar files for which we don't have build scripts.
https://issues.apache.org/jira/browse/DERBY-4183
DERBY-151 Thread termination -> XSDG after operation is 'complete'
https://issues.apache.org/jira/browse/DERBY-151
DERBY-1191 Some SQLExceptions, for example those generated from BrokeredStatements, do not print to derby.log even when derby.stream.error.logSeverityLevel=0
https://issues.apache.org/jira/browse/DERBY-1191
DERBY-4272 SQL Authorization Support for dblook
https://issues.apache.org/jira/browse/DERBY-4272
DERBY-873 OSGi bundle activator not JSR169 compliant
https://issues.apache.org/jira/browse/DERBY-873
DERBY-4137 OOM issue using XA with timeouts
https://issues.apache.org/jira/browse/DERBY-4137
DERBY-3788 Provide a zero-admin way of updating the statisitcs of an index
https://issues.apache.org/jira/browse/DERBY-3788
DERBY-4241 Improve transition from read-only to writable Clob representation
https://issues.apache.org/jira/browse/DERBY-4241

You may edit this subscription at:
https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?subId=10396&filterId=12310751

[jira] Issue Comment Edited: (DERBY-1664) Derby startup time is too slow

2009-11-10T23:38:39Z

[ https://issues.apache.org/jira/browse/DERBY-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766531#action_12766531 ]

martin edited comment on DERBY-1664 at 11/11/09 7:37 AM:
---------------------------------------------------------

Startup is slow especially when database was not shut down properly. This seems be user's problem, as it is his responsibility to ensure proper shutdown procedure. Here is a little problem:
while embedded engine starts silently at user's request, user should shutdown engine explicitly.
While first part conforms zero administration claim, the second part is in direct contradiction of the claim.

Typical scenario is: application uses a connection pool - it may connect to a production database or local testing database. For testing database, embedded derby is used. Connection pool like C3P0 can start the embedded driver, but has no method for shutdown. When application starts next times with embedded database, starts are getting slower and slower as database grows.

I think shutdown hooks installed at engine startup should solve the situation. This was proposed long time ago, but never implemented.

was (Author: mstanik):
Startup is slow especially when database was not shut down properly. This seems be user's problem, as it is his responsibility to ensure proper shutdown procedure. Here is a little problem:
while embedded engine starts silently at user's request, user should shutdown engine explicitly.
While first part conforms zero administration claim, the second part is in direct contradiction of the claim.

Typical scenario is: application uses a connection pool - it may connect to a production database or local testing database. For testing database, embedded derby is used. Connection pool can start the embedded driver, but has no method for shutdown. When application starts next times with embedded database, starts are getting slower and slower as database grows.

I think shutdown hooks installed at engine startup should solve the situation. This was proposed long time ago, but never implemented.

> Derby startup time is too slow
> ------------------------------
>
> Key: DERBY-1664
> URL: https://issues.apache.org/jira/browse/DERBY-1664
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: David Van Couvering
> Attachments: perftest.diff
>
>
> I know it's hard to measure what "too slow" is, but this is a common complaint and this affects overall perception of Derby. This appears to be related to another common complaint that it takes too long to create tables. I am marking this as Urgent because of the impact it has to Derby perception and the fact that the 10.2 release is going to get such wide distribution through the Sun JDK.
> For background, see http://www.nabble.com/Startup-time-tf2012748.html#a5531684

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4253) documentation should indicate that a database cannot be upgraded if already booted in soft upgrade mode

2009-11-10T18:37:27Z

[ https://issues.apache.org/jira/browse/DERBY-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton updated DERBY-4253:
-----------------------------------

Attachment: rrefattribupgrade.html
docs.diff

The proposed documentation text seems quite helpful to me, and the
location for it seems appropriate too.

See attached HTML file for how it looks, edited in place.

Please let me know what you think.

> documentation should indicate that a database cannot be upgraded if already booted in soft upgrade mode
> -------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4253
> URL: https://issues.apache.org/jira/browse/DERBY-4253
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.6.0.0
> Reporter: Kathey Marsden
> Assignee: Bryan Pendleton
> Priority: Minor
> Attachments: docs.diff, rrefattribupgrade.html
>
>
> The documentation should indicate that you cannot perform a full upgrade on a database already booted in soft upgrade mode. If a database is already booted in soft upgrade mode, the upgrade=true attribute will have no effect. If a database is already booted in soft upgrade mode, you can shutdown the database with the shutdown=true attribute and then connect with upgrade=true to perform the upgrade.
> Perhaps a good place for this might be at:
> http://db.apache.org/derby/docs/10.4/ref/rrefattribupgrade.html
> See the derby-user thread:
> http://www.nabble.com/Hard-upgrade-failing--td23826558.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4435) Emptying index fails with NPE doing replacement import of empty file

2009-11-10T16:28:30Z

[ https://issues.apache.org/jira/browse/DERBY-4435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776193#action_12776193 ]

Mamta A. Satoor commented on DERBY-4435:
----------------------------------------

Committed fix into trunk with revision 834725. The fix involves initializing the collation arrary correctly.

> Emptying index fails with NPE doing replacement import of empty file
> --------------------------------------------------------------------
>
> Key: DERBY-4435
> URL: https://issues.apache.org/jira/browse/DERBY-4435
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.3.0
> Environment: Doing replacement import resulting in an empty table, where the table has at least one index.
> Reporter: Kristian Waagan
> Assignee: Mamta A. Satoor
> Fix For: 10.6.0.0
>
> Attachments: Derby4435Repro.java
>
>
> When importing data from an empty file, with the replacement option enabled (non-zero last argument in the import procedure call), Derby fails with a NullPointerException when emptying the index(es) .
> Stack trace, insane build:
> java.sql.SQLException: Import error on line 1 of file [snip]: Java exception: ': java.lang.NullPointerException'.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
> ...
> Caused by: java.lang.NullPointerException
> at org.apache.derby.impl.sql.execute.InsertResultSet.emptyIndexes(InsertResultSet.java:2348)
> at org.apache.derby.impl.sql.execute.InsertResultSet.updateAllIndexes(InsertResultSet.java:1820)
> at org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(InsertResultSet.java:1356)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:444)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
> ... 44 more
> Stack trace, sane build:
> java.sql.SQLException: The exception 'java.sql.SQLException: An internal error was identified by RawStore module.' was thrown while evaluating an expression.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
> ...
> Caused by: ERROR 40XT0: An internal error was identified by RawStore module.
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276)
> at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:917)
> at org.apache.derby.impl.store.access.RAMTransaction.abort(RAMTransaction.java:1985)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(GenericLanguageConnectionContext.java:1496)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(GenericLanguageConnectionContext.java:1404)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(TransactionResourceImpl.java:244)
> at org.apache.derby.impl.jdbc.EmbedConnection.rollback(EmbedConnection.java:1764)
> ... 40 more
> A quick investigation suggests DERBY-2537 added the code that fails.
> Problem reported by a user on the Derby user list, see http://thread.gmane.org/gmane.comp.apache.db.derby.user/11764

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4435) Emptying index fails with NPE doing replacement import of empty file

2009-11-10T16:28:30Z

[ https://issues.apache.org/jira/browse/DERBY-4435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mamta A. Satoor updated DERBY-4435:
-----------------------------------

Fix Version/s: 10.6.0.0

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-4439) NullPointerException at bind time when selecting from VALUES NULL

2009-11-10T09:01:27Z

[ https://issues.apache.org/jira/browse/DERBY-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mamta A. Satoor reassigned DERBY-4439:
--------------------------------------

Assignee: Mamta A. Satoor

> NullPointerException at bind time when selecting from VALUES NULL
> -----------------------------------------------------------------
>
> Key: DERBY-4439
> URL: https://issues.apache.org/jira/browse/DERBY-4439
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Mamta A. Satoor
> Priority: Minor
>
> I see a NullPointerException when I try the following query:
> ij> select x*2 from (values null) v(x);
> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> It should fail gracefully instead, like this similar query:
> ij> select x from (values null) v(x);
> ERROR 42X07: Null is only allowed in a VALUES clause within an INSERT statement.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-4435) Emptying index fails with NPE doing replacement import of empty file

2009-11-10T08:59:27Z

[ https://issues.apache.org/jira/browse/DERBY-4435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mamta A. Satoor reassigned DERBY-4435:
--------------------------------------

Assignee: Mamta A. Satoor

> Emptying index fails with NPE doing replacement import of empty file
> --------------------------------------------------------------------
>
> Key: DERBY-4435
> URL: https://issues.apache.org/jira/browse/DERBY-4435
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.3.0
> Environment: Doing replacement import resulting in an empty table, where the table has at least one index.
> Reporter: Kristian Waagan
> Assignee: Mamta A. Satoor
> Attachments: Derby4435Repro.java
>
>
> When importing data from an empty file, with the replacement option enabled (non-zero last argument in the import procedure call), Derby fails with a NullPointerException when emptying the index(es) .
> Stack trace, insane build:
> java.sql.SQLException: Import error on line 1 of file [snip]: Java exception: ': java.lang.NullPointerException'.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
> ...
> Caused by: java.lang.NullPointerException
> at org.apache.derby.impl.sql.execute.InsertResultSet.emptyIndexes(InsertResultSet.java:2348)
> at org.apache.derby.impl.sql.execute.InsertResultSet.updateAllIndexes(InsertResultSet.java:1820)
> at org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(InsertResultSet.java:1356)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:444)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
> ... 44 more
> Stack trace, sane build:
> java.sql.SQLException: The exception 'java.sql.SQLException: An internal error was identified by RawStore module.' was thrown while evaluating an expression.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
> ...
> Caused by: ERROR 40XT0: An internal error was identified by RawStore module.
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276)
> at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:917)
> at org.apache.derby.impl.store.access.RAMTransaction.abort(RAMTransaction.java:1985)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(GenericLanguageConnectionContext.java:1496)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(GenericLanguageConnectionContext.java:1404)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(TransactionResourceImpl.java:244)
> at org.apache.derby.impl.jdbc.EmbedConnection.rollback(EmbedConnection.java:1764)
> ... 40 more
> A quick investigation suggests DERBY-2537 added the code that fails.
> Problem reported by a user on the Derby user list, see http://thread.gmane.org/gmane.comp.apache.db.derby.user/11764

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Regression Test Report - Daily 834146 - Sun DBTG

2009-11-10T08:55:42Z

[Auto-generated mail]

*Daily* 834146/2009-11-09 18:02:12 MET

Failed Tests OK Skip Duration Suite
-------------------------------------------------------
*Jvm: 1.6*
lin
0 11702 11702 0 1032.59% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 56.70% derbyall
0 2 2 0 618.97% compatibility
0 2 2 0 .% demoSuite
sles
0 11702 11702 0 647.86% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 47.99% derbyall
0 2 2 0 287.80% compatibility
0 2 2 0 .% demoSuite
sol
0 11702 11702 0 819.16% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 43.73% derbyall
0 2 2 0 315.85% compatibility
0 2 2 0 .% demoSuite
solN+1
0 11702 11702 0 140.79% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 66.42% derbyall
0 2 2 0 304.85% compatibility
0 2 2 0 .% demoSuite
sparc
NA NA NA NA suitesAll
NA NA NA NA jdbcapiAutoLoad
NA NA NA NA JDBCDriversAll
NA NA NA NA JDBCDriversClient
NA NA NA NA JDBCDriversEmbedded
NA NA NA NA derbyall
NA NA NA NA compatibility
NA NA NA NA demoSuite
vista
0 11696 11696 0 130.03% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 58.88% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
vista-64
0 11696 11696 0 189.20% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 57.79% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
w2003
0 11696 11696 0 229.24% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 70.08% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-834146.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/834146_bySig.html

*Jvm: 1.5*
lin
0 222 222 0 53.82% derbyall
0 9912 9912 0 1720.72% suitesAll
sles
0 222 222 0 48.12% derbyall
0 9912 9912 0 1109.49% suitesAll
sol
0 222 222 0 45.97% derbyall
0 9912 9912 0 1525.10% suitesAll
solN+1
0 222 222 0 60.60% derbyall
0 9912 9912 0 1411.43% suitesAll
sparc
NA NA NA NA derbyall
NA NA NA NA suitesAll
vista
0 222 222 0 45.57% derbyall
0 9906 9906 0 916.83% suitesAll
vista-64
0 222 222 0 58.17% derbyall
0 9906 9906 0 212.99% suitesAll
w2003
0 222 222 0 54.94% derbyall
0 9906 9906 0 569.54% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-834146.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/FailReports/834146_bySig.html

*Jvm: 1.4*
lin
0 219 219 2 54.12% derbyall
0 9759 9759 0 1565.90% suitesAll
sles
0 219 219 2 42.98% derbyall
0 9759 9759 0 916.72% suitesAll
sol
0 219 219 2 42.11% derbyall
0 9759 9759 0 1232.81% suitesAll
solN+1
0 219 219 2 58.86% derbyall
0 9759 9759 0 1319.97% suitesAll
sparc
NA NA NA NA derbyall
NA NA NA NA suitesAll
vista
NA NA NA NA derbyall
NA NA NA NA suitesAll
vista-64
0 219 219 2 57.08% derbyall
0 9753 9753 0 216.85% suitesAll
w2003
0 219 219 2 56.99% derbyall
0 9759 9759 0 568.61% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-834146.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/FailReports/834146_bySig.html

.......................................................
*Jvm: 1.7*
lin
0 11702 11702 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
0 2 2 0 .% compatibility
0 2 2 0 .% demoSuite
sol
0 11702 11702 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
0 2 2 0 .% compatibility
0 2 2 0 .% demoSuite
vista-64
0 11696 11696 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-834146.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/834146_bySig.html

*Jvm: phoneME*
ubuntu
0 4410 4410 0 .% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/javaME/testing/Limited/testSummary-834146.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/javaME/FailReports/834146_bySig.html

-------------------------------------------------------

Changes in http://dbtg.foundry.sun.com/derby/test/Daily/UpdateInfo/834146.txt

( All results in http://dbtg.foundry.sun.com/derby/test/ )

[jira] Commented: (DERBY-4422) Extremely slow subqueries when subquerying on strings

2009-11-10T08:55:28Z

[ https://issues.apache.org/jira/browse/DERBY-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775939#action_12775939 ]

Knut Anders Hatlen commented on DERBY-4422:
-------------------------------------------

Hi Bryan,

The condition you quoted was for flattening into a normal join. There is also an option to flatten into an exists join (http://db.apache.org/derby/docs/10.5/tuning/ctuntransform25868.html) which does not have that condition and should apply if the outer DISTINCT does not provide that guarantee.

I'm not sure, though, if the guarantee provided by the outer DISTINCT is what the manual talks about, or if it actually requires that the sub-query does not return duplicates, even with the inner DISTINCT removed.

> Extremely slow subqueries when subquerying on strings
> -----------------------------------------------------
>
> Key: DERBY-4422
> URL: https://issues.apache.org/jira/browse/DERBY-4422
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.5.3.0
> Environment: Suse Unix 10.3.
> Reporter: Tony Brusseau
> Attachments: badqp.txt, derby.log, fixed-time-derby.log, goodqp.txt, SQLFile1.sqlaa.gz, SQLFile1.sqlab.gz, SQLFile2.sqlaa.gz, SQLFile2.sqlab.gz, SQLFile2.sqlac.gz, tmp2.sql, unlimited-time-derby.log
>
>
> SELECT DISTINCT C.INTERNAL_ID
> FROM OC_CONCEPTS C
> WHERE
> (C.INTERNAL_ID IN (SELECT DISTINCT OCS.CONCEPT_ID FROM OC_CONCEPT_STRINGS OCS WHERE OCS.CONCEPT_ID=1))
> Both queries above are trivial and they are both acting on fully indexed primary key columns. This query runs just fine.
> However, when I make the small modification of searching on an indexed text column in the sub query, it takes over 6 seconds to run, even though both queries independently take < 1ms run.
> SELECT DISTINCT C.INTERNAL_ID
> FROM OC_CONCEPTS C
> WHERE
> (C.INTERNAL_ID IN (SELECT DISTINCT OCS.CONCEPT_ID FROM OC_CONCEPT_STRINGS OCS WHERE OCS.NL_LC = 'dash'))

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4422) Extremely slow subqueries when subquerying on strings

2009-11-10T08:05:30Z

[ https://issues.apache.org/jira/browse/DERBY-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775923#action_12775923 ]

Bryan Pendleton commented on DERBY-4422:
----------------------------------------

Does this indicate a weakness in the Derby query-flattening algorithm? I read through
http://db.apache.org/derby/docs/10.5/tuning/ctuntransform36368.html
and was unsure whether Derby should have been able to flatten this query
automatically or not. It seems like the crucial bit is:

"There is a uniqueness condition that ensures that the subquery does not introduce
any duplicates if it is flattened into the outer query block"

But I think that the DISTINCT in the *outer* query should have provided such a guarantee.

I think that the DISTINCT in the *subquery* is unnecessary, due to:
http://db.apache.org/derby/docs/10.5/tuning/ctuntransform867165.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4422) Extremely slow subqueries when subquerying on strings

2009-11-10T07:55:27Z

[ https://issues.apache.org/jira/browse/DERBY-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775919#action_12775919 ]

Knut Anders Hatlen commented on DERBY-4422:
-------------------------------------------

I downloaded the database and ran the queries, and I see the same behaviour.

One possible workaround is to rewrite the IN query to a join manually. So instead of

SELECT DISTINCT C.INTERNAL_ID
FROM OC_CONCEPTS C
WHERE
(C.INTERNAL_ID IN (SELECT DISTINCT OCS.CONCEPT_ID FROM OC_CONCEPT_STRINGS OCS WHERE OCS.NL_LC = 'dash'))

try this equivalent query

SELECT DISTINCT C.INTERNAL_ID
FROM OC_CONCEPTS C, OC_CONCEPT_STRINGS OCS
WHERE C.INTERNAL_ID = OCS.CONCEPT_ID AND OCS.NL_LC = 'dash'

The latter query is much faster in my environment.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4439) NullPointerException at bind time when selecting from VALUES NULL

2009-11-10T06:53:27Z

[ https://issues.apache.org/jira/browse/DERBY-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775439#action_12775439 ]

Knut Anders Hatlen commented on DERBY-4439:
-------------------------------------------

I'm not sure if "insert into u select * from (values null) as X" is supposed to be accepted.

NULL is an <implicitly typed value specification> (see SQL:2003, part 2, 6.5 <contextually typed value specification>), which can be found in a <contextually typed value specification>, in a <cast specification>, or in a <default clause>.

In "insert into u select * from (values null) as X", the "values null" part is a <table value constructor>, which as far as I can see does not accept a <contextually typed value specification>. In "insert into u values null", on the other hand, it's a <contextually typed table value constructor>, which does accept contextually typed values.

> NullPointerException at bind time when selecting from VALUES NULL
> -----------------------------------------------------------------
>
> Key: DERBY-4439
> URL: https://issues.apache.org/jira/browse/DERBY-4439
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
>
> I see a NullPointerException when I try the following query:
> ij> select x*2 from (values null) v(x);
> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> It should fail gracefully instead, like this similar query:
> ij> select x from (values null) v(x);
> ERROR 42X07: Null is only allowed in a VALUES clause within an INSERT statement.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Blocking new connection requests in Derby

2009-11-10T06:52:53Z

Rick Hillegas wrote:

> Kristian Waagan wrote:
>> Rick Hillegas wrote:
>>> Thanks for writing up this spec, Kristian. If I understand
>>> correctly, you are proposing a mechanism for rejecting new
>>> connections to a database to handle the following situations:
>>>
>>> 1) Eliminate race conditions and ugly, puzzling diagnostic messages
>>> during database shutdown and database deletion.
>>>
>>> 2) Protect extended database maintenance from corrupting, concurrent
>>> access.
>>>
>>> It seems to me that (1) is a very reasonable use case and probably
>>> doesn't need any additional api: by default a database
>>> shutdown/deletion should prevent other users from connecting and
>>> should, in fact, kick out all other users.
>>>
>>> Can you give some use-cases for situation (2)?
>>
>> Hi Rick,
>>
>> Situation (2) arises when doing maintenance operations, and is
>> basically an alternative to shutting down an application or the
>> database server. The goal is to ensure no other connections are made
>> to the database. This include boot- and creation-attempts. Some
>> use-cases:
>> a) You simply want to block out all users without shutting down the JVM.
>> b) You need to hard-upgrade the database.
>> In this situation, you don't want anyone to boot the database
>> before you (after it has been shut down).
>> c) You need to (re-)encrypt the database.
>> Same as above.
>>
>> The most problematic situation today may be when you have a network
>> server with several active databases, say one for each of your
>> customers. How do you currently block access to one of the databases
>> without affecting the others?
>> We don't have system privileges (yet), so I can only think of using
>> the Java security manager, moving the database away (might be very
>> costly for large databases) or possibly disabling users at the
>> system-wide level. None of these mechanisms are easy to use with the
>> current level of tooling.
>>
>> Also, by throwing a known exception stating the database has been
>> temporarily blocked, properly written applications can detect this
>> and simply try to connect again after waiting for a while.
>>
>> Finally, after thinking more about it, this feature would need a
>> different API to ensure *exclusive* access to the database. The
>> reason is that Derby has to boot a database to determine if the user
>> is the DBO (or a DBA). The rejection should happen prior to booting
>> the database. I have some thoughts about this, but let us first
>> discuss the need for such a feature.
>> Just to be clear, the spec would need rewriting to be accurate for (2).
>>
>>
>> I agree (1) and (2) are different situations, and that (1) alone will
>> be enough to address many issues. I don't have any problems dropping
>> (2) if it isn't considered useful.
>>
>>
>> Thanks,
> Thanks for the quick response, Kristian. It seems to me that (2b) and
> (2c) are similar to (1) in that they should be the default behavior.
> My gut feeling is that (1) + (2b) + (2c) are very useful: we should
> always freeze out other users when performing these operations. (2a)
> is still murky to me and I would be tempted to not design a
> user-invokable api for this until we know more about who would use it.
> It makes sense to me to log an enhancement JIRA for (2a) but not
> design a user-invokable api for it until a user turns up who needs it.
> It may be that that user will have experience with a good api from
> another database, which we could mimic.

Rick,

Your reservations sound reasonable.
I'll trim down the spec and attach it to a Jira (not yet created) for
further review.

I'm still not sure if we can cover (2b) with default behavior, though.
My understanding is that the database has to be shut down before you
make the connection to hard-upgrade the database. This means that you
have to somehow ensure nobody else can connect to the database in the
time-window from when you shut down the database to the connection with
the upgrade attributes is accepted. This process has to happen as two
separate connections.

Is my understanding wrong?
You still have to load the new Derby jars to upgrade, and in most
systems I assume this requires you to take down the application /
server. Using OSGi may be an exception...

Let me investigate a bit more, I'll post my findings to the list. The
problem may be "of academic interest only" ;)

Regards,
--
Kristian

>
> Thanks,
> -Rick

[jira] Commented: (DERBY-4430) Make ij's SHOW and DESCRIBE commands more db agnostic

2009-11-10T05:45:27Z

[ https://issues.apache.org/jira/browse/DERBY-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775413#action_12775413 ]

Knut Anders Hatlen commented on DERBY-4430:
-------------------------------------------

I've tested the patch with MySQL (where storesMixedCaseIdentifier() returns true) and PostgreSQL (where storesLowerCaseIdentifier() returns true). The SHOW and DESCRIBE commands now work fine on those databases too.

> Make ij's SHOW and DESCRIBE commands more db agnostic
> -----------------------------------------------------
>
> Key: DERBY-4430
> URL: https://issues.apache.org/jira/browse/DERBY-4430
> Project: Derby
> Issue Type: Improvement
> Components: Tools
> Affects Versions: 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Sylvain Leroux
> Priority: Minor
> Attachments: DERBY-4430.ij.out, DERBY-4430.patch, DERBY-4430.sql
>
>
> ij's SHOW and DESCRIBE commands use DatabaseMetaData in order to be portable to other databases than Derby, and in many cases they work fine with other databases. However, the variants of the commands that take a table name or a schema name assume that unquoted identifiers are converted to and stored in upper case internally. This is not true for all databases, and since these commands don't accept quoted identifiers, there's currently no way to access tables/schemas that are not all upper case.
> One possible fix is to make the identifier() method in ij.jj use the DatabaseMetaData methods storesLowerCaseIdentifiers(), storesMixedCaseIdentifiers() and storesUpperCaseIdentifiers() to decide whether it should convert the identifier to lower case, keep it unchanged, or convert it to upper case. Currently, that method always converts the identifiers to upper case.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Blocking new connection requests in Derby

2009-11-10T05:37:51Z

Kristian Waagan wrote:

> Rick Hillegas wrote:
>> Thanks for writing up this spec, Kristian. If I understand correctly,
>> you are proposing a mechanism for rejecting new connections to a
>> database to handle the following situations:
>>
>> 1) Eliminate race conditions and ugly, puzzling diagnostic messages
>> during database shutdown and database deletion.
>>
>> 2) Protect extended database maintenance from corrupting, concurrent
>> access.
>>
>> It seems to me that (1) is a very reasonable use case and probably
>> doesn't need any additional api: by default a database
>> shutdown/deletion should prevent other users from connecting and
>> should, in fact, kick out all other users.
>>
>> Can you give some use-cases for situation (2)?
>
> Hi Rick,
>
> Situation (2) arises when doing maintenance operations, and is
> basically an alternative to shutting down an application or the
> database server. The goal is to ensure no other connections are made
> to the database. This include boot- and creation-attempts. Some
> use-cases:
> a) You simply want to block out all users without shutting down the JVM.
> b) You need to hard-upgrade the database.
> In this situation, you don't want anyone to boot the database
> before you (after it has been shut down).
> c) You need to (re-)encrypt the database.
> Same as above.
>
> The most problematic situation today may be when you have a network
> server with several active databases, say one for each of your
> customers. How do you currently block access to one of the databases
> without affecting the others?
> We don't have system privileges (yet), so I can only think of using
> the Java security manager, moving the database away (might be very
> costly for large databases) or possibly disabling users at the
> system-wide level. None of these mechanisms are easy to use with the
> current level of tooling.
>
> Also, by throwing a known exception stating the database has been
> temporarily blocked, properly written applications can detect this and
> simply try to connect again after waiting for a while.
>
> Finally, after thinking more about it, this feature would need a
> different API to ensure *exclusive* access to the database. The
> reason is that Derby has to boot a database to determine if the user
> is the DBO (or a DBA). The rejection should happen prior to booting
> the database. I have some thoughts about this, but let us first
> discuss the need for such a feature.
> Just to be clear, the spec would need rewriting to be accurate for (2).
>
>
> I agree (1) and (2) are different situations, and that (1) alone will
> be enough to address many issues. I don't have any problems dropping
> (2) if it isn't considered useful.
>
>
> Thanks,

Thanks for the quick response, Kristian. It seems to me that (2b) and
(2c) are similar to (1) in that they should be the default behavior. My
gut feeling is that (1) + (2b) + (2c) are very useful: we should always
freeze out other users when performing these operations. (2a) is still
murky to me and I would be tempted to not design a user-invokable api
for this until we know more about who would use it. It makes sense to me
to log an enhancement JIRA for (2a) but not design a user-invokable api
for it until a user turns up who needs it. It may be that that user will
have experience with a good api from another database, which we could mimic.

Thanks,
-Rick

Re: Blocking new connection requests in Derby

2009-11-10T05:19:05Z

Rick Hillegas wrote:

> Thanks for writing up this spec, Kristian. If I understand correctly,
> you are proposing a mechanism for rejecting new connections to a
> database to handle the following situations:
>
> 1) Eliminate race conditions and ugly, puzzling diagnostic messages
> during database shutdown and database deletion.
>
> 2) Protect extended database maintenance from corrupting, concurrent
> access.
>
> It seems to me that (1) is a very reasonable use case and probably
> doesn't need any additional api: by default a database
> shutdown/deletion should prevent other users from connecting and
> should, in fact, kick out all other users.
>
> Can you give some use-cases for situation (2)?

Hi Rick,

Situation (2) arises when doing maintenance operations, and is basically
an alternative to shutting down an application or the database server.
The goal is to ensure no other connections are made to the database.
This include boot- and creation-attempts. Some use-cases:
a) You simply want to block out all users without shutting down the JVM.
b) You need to hard-upgrade the database.
In this situation, you don't want anyone to boot the database before
you (after it has been shut down).
c) You need to (re-)encrypt the database.
Same as above.

The most problematic situation today may be when you have a network
server with several active databases, say one for each of your
customers. How do you currently block access to one of the databases
without affecting the others?
We don't have system privileges (yet), so I can only think of using the
Java security manager, moving the database away (might be very costly
for large databases) or possibly disabling users at the system-wide
level. None of these mechanisms are easy to use with the current level
of tooling.

Also, by throwing a known exception stating the database has been
temporarily blocked, properly written applications can detect this and
simply try to connect again after waiting for a while.

Finally, after thinking more about it, this feature would need a
different API to ensure *exclusive* access to the database. The reason
is that Derby has to boot a database to determine if the user is the DBO
(or a DBA). The rejection should happen prior to booting the database. I
have some thoughts about this, but let us first discuss the need for
such a feature.
Just to be clear, the spec would need rewriting to be accurate for (2).

I agree (1) and (2) are different situations, and that (1) alone will be
enough to address many issues. I don't have any problems dropping (2) if
it isn't considered useful.

Thanks,
--
Kristian

>
> Thanks,
> -Rick
>
> Kristian Waagan wrote:
>> Hello,
>>
>> When working on the feature of dropping databases (in-memory
>> primarily), it became apparent that the possibility to temporarily
>> block incoming connection attempts would be very useful.
>>
>> I have started on a spec for this feature. Today I was supposed to
>> continue working on it, but got lost in code trying to write a
>> prototype to verify some claims instead :)
>> I'm choosing to post it now anyway to see if I get any feedback on
>> whether this feature would be useful in other scenarios. If so, there
>> may be new requirements not included in the current spec.
>> Verification of what I have written about authentication and
>> authorization is also definitely required.
>>
>> If I get positive feedback, I can create a Jira and post a prototype
>> shortly after. This should allow us to make progress after our
>> initial discussion here. If you want to have a quick look at the test
>> I threw at Derby (currently doesn't work because all the required
>> code hasn't been posted, specifically the drop database code), see
>> the class DropWhileConnectingTest in patch 1a attached to DERBY-4436.
>>
>>
>> As a side note, most of my work so far has been with the embedded
>> driver. I suspect getting the network client to behave as well as the
>> embedded driver may be harder.
>>
>>
>> Regards,
>
>

[jira] Created: (DERBY-4440) Intermittent Java deadlock when running LobStreamsTest with insane jars

2009-11-10T04:56:28Z

Intermittent Java deadlock when running LobStreamsTest with insane jars
-----------------------------------------------------------------------

Key: DERBY-4440
URL: https://issues.apache.org/jira/browse/DERBY-4440
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.6.0.0
Environment: Dual core CPU at 3.2 GHz, OpenSolaris, Java HotSpot(TM) Client VM (14.1-b02 mixed mode)
Reporter: Kristian Waagan
Attachments: java-deadlock.txt

The following deadlock was obtained by using jstack when the test LobStreamsTest hung:

Found one Java-level deadlock:
=============================
"Finalizer":
waiting to lock monitor 0x080f2038 (object 0xceb8ef08, a org.apache.derby.impl.store.raw.data.StoredPage),
which is held by "main"
"main":
waiting to lock monitor 0x082b5ef8 (object 0xceb98fe8, a org.apache.derby.impl.store.raw.data.BaseContainerHandle),
which is held by "Finalizer"

The deadlock is highly intermittent. In many cases the test pass, and when it fails it is mostly with a different symptom than a deadlock (assert error or an IOException / SQLException).
The problems seem to be triggered by using Clobs, but I don't know if it may be triggered in other environments as well.

It is likely that DERBY-3844 describes the assert caused by the same underlying issue.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4440) Intermittent Java deadlock when running LobStreamsTest with insane jars

2009-11-10T04:56:28Z

[ https://issues.apache.org/jira/browse/DERBY-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kristian Waagan updated DERBY-4440:
-----------------------------------

Attachment: java-deadlock.txt

Attached thread dump.

> Intermittent Java deadlock when running LobStreamsTest with insane jars
> -----------------------------------------------------------------------
>
> Key: DERBY-4440
> URL: https://issues.apache.org/jira/browse/DERBY-4440
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.6.0.0
> Environment: Dual core CPU at 3.2 GHz, OpenSolaris, Java HotSpot(TM) Client VM (14.1-b02 mixed mode)
> Reporter: Kristian Waagan
> Attachments: java-deadlock.txt
>
>
> The following deadlock was obtained by using jstack when the test LobStreamsTest hung:
> Found one Java-level deadlock:
> =============================
> "Finalizer":
> waiting to lock monitor 0x080f2038 (object 0xceb8ef08, a org.apache.derby.impl.store.raw.data.StoredPage),
> which is held by "main"
> "main":
> waiting to lock monitor 0x082b5ef8 (object 0xceb98fe8, a org.apache.derby.impl.store.raw.data.BaseContainerHandle),
> which is held by "Finalizer"
> The deadlock is highly intermittent. In many cases the test pass, and when it fails it is mostly with a different symptom than a deadlock (assert error or an IOException / SQLException).
> The problems seem to be triggered by using Clobs, but I don't know if it may be triggered in other environments as well.
> It is likely that DERBY-3844 describes the assert caused by the same underlying issue.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4432) Memory leak when attempting to boot non-existing database with the in-memory back end

2009-11-10T02:46:28Z

[ https://issues.apache.org/jira/browse/DERBY-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775372#action_12775372 ]

Kristian Waagan commented on DERBY-4432:
----------------------------------------

Regression tests ran cleanly on trunk with patch 1a.
Committed patch 1a to trunk with revision 834418.

Will check if it is suited for back-port and rerun tests on the 10.5 branch if that is the case.

> Memory leak when attempting to boot non-existing database with the in-memory back end
> -------------------------------------------------------------------------------------
>
> Key: DERBY-4432
> URL: https://issues.apache.org/jira/browse/DERBY-4432
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.5.3.0, 10.6.0.0
> Environment: In-memory back end and large amount of boot attempts of non-existing databases.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.6.0.0
>
> Attachments: derby-4432-1a-mem_leak_fix.diff, derby-4432-1a-mem_leak_fix.stat
>
>
> When attempting to boot a non-existing database with the in-memory back end, a DataStore is created and referenced by a map. Since the database doesn't exist, Derby won't use the DataStore again and it will hang around indefinitely in VFMemoryStorageFactory (or until the same database is actually created, in which case the data store will be used).
> FYI, storage factory instances are instantiated liberally, including for the same service (i.e. six instances of VFMemoryStorageFactory may be created to boot "jdbc:derby:memory:myDB").

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4432) Memory leak when attempting to boot non-existing database with the in-memory back end

2009-11-10T02:46:28Z

[ https://issues.apache.org/jira/browse/DERBY-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kristian Waagan updated DERBY-4432:
-----------------------------------

Fix Version/s: 10.6.0.0

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4102) Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K

2009-11-10T02:32:27Z

[ https://issues.apache.org/jira/browse/DERBY-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775368#action_12775368 ]

Knut Anders Hatlen commented on DERBY-4102:
-------------------------------------------

The intermittent failure in testBlobWrite3Param() is already logged as DERBY-3844.

> Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K
> -----------------------------------------------------------------------------
>
> Key: DERBY-4102
> URL: https://issues.apache.org/jira/browse/DERBY-4102
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.1.0, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Kristian Waagan
> Attachments: CastExc.java, derby-4102-1a.diff, derby-4102-1a.stat, java-deadlock.txt
>
>
> The code below results in an assert error (with sane jars) or a ClassCastException (with insane jars):
> PreparedStatement ps = c.prepareStatement("values cast(? as blob)");
> int len = 32 * 1024;
> ps.setBinaryStream(1, new ByteArrayInputStream(new byte[len]), len);
> ResultSet rs = ps.executeQuery();
> while (rs.next()) {
> rs.getBlob(1);
> }
> If len < 32K there is no error.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-4102) Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K

2009-11-10T02:14:27Z

[ https://issues.apache.org/jira/browse/DERBY-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kristian Waagan updated DERBY-4102:
-----------------------------------

Attachment: java-deadlock.txt

The Java deadlock seen when running tests.jdbcapi.LobStreamsTest (dual core machine, 3.2 GHz).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-4102) Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K

2009-11-10T02:12:28Z

[ https://issues.apache.org/jira/browse/DERBY-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775362#action_12775362 ]

Kristian Waagan edited comment on DERBY-4102 at 11/10/09 10:11 AM:
-------------------------------------------------------------------

Testing this patch again, I have observed an intermittent failure both with a clean trunk and with a patched trunk (patch DERBY-4102 1a).

Running with a sane build:
1) testBlobWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
at org.apache.derby.impl.store.raw.data.BasePage.unlatch(BasePage.java:1365)
at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:152)
at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
at java.io.DataInputStream.read(DataInputStream.java:132)
at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:116)
at org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
at org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:184)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

This associated code in BasePage is:
public void unlatch() {
if (SanityManager.DEBUG) {
SanityManager.ASSERT(isLatched());
}
releaseExclusive();
}

1) testBlobWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)java.io.IOException: ERROR 40XD0: Container has been closed.
at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:159)
at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
at java.io.DataInputStream.read(DataInputStream.java:132)
at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:116)
at org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
at org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:184)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

The origin of the real exception is lost here (not chained), but investigation shows where it comes from:
at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276)
at org.apache.derby.impl.store.raw.data.BaseContainerHandle.checkOpen(BaseContainerHandle.java:978)
at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getPage(BaseContainerHandle.java:317)
at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:146)
at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
...

The Java deadlock (see attached dump for details):
Found one Java-level deadlock:
=============================
"Finalizer":
waiting to lock monitor 0x080f2038 (object 0xceb8ef08, a org.apache.derby.impl.store.raw.data.StoredPage),
which is held by "main"
"main":
waiting to lock monitor 0x082b5ef8 (object 0xceb98fe8, a org.apache.derby.impl.store.raw.data.BaseContainerHandle),
which is held by "Finalizer"

Since the problem occurs both with and without the patch, I plan to commit it.
I will log a new Jira for the deadlock and the asserts/exceptions. I assume they are all symptoms of the same problem, arising due to slightly different timing.

was (Author: kristwaa):
Testing this patch again, I have observed an intermittent failure both with a clean trunk and with a patched trunk (patch DERBY-4102 1a).

Running with a sane build:
1) testBlobWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
at org.apache.derby.impl.store.raw.data.BasePage.unlatch(BasePage.java:1365)
at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:152)
at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
at java.io.DataInputStream.read(DataInputStream.java:132)
at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:116)
at org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
at org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:184)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

This associated code in BasePage is:
public void unlatch() {
if (SanityManager.DEBUG) {
SanityManager.ASSERT(isLatched());
}
releaseExclusive();
}

1) testBlobWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)java.io.IOException: ERROR 40XD0: Container has been closed.
at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:159)
at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
at java.io.DataInputStream.read(DataInputStream.java:132)
at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:116)
at org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
at org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:184)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

The origin of the real exception is lost here (not chained), and when I was about to investigate where it

The Java deadlock (see attached dump for details):

> Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K
> -----------------------------------------------------------------------------
>
> Key: DERBY-4102
> URL: https://issues.apache.org/jira/browse/DERBY-4102
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.1.0, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Kristian Waagan
> Attachments: CastExc.java, derby-4102-1a.diff, derby-4102-1a.stat
>
>
> The code below results in an assert error (with sane jars) or a ClassCastException (with insane jars):
> PreparedStatement ps = c.prepareStatement("values cast(? as blob)");
> int len = 32 * 1024;
> ps.setBinaryStream(1, new ByteArrayInputStream(new byte[len]), len);
> ResultSet rs = ps.executeQuery();
> while (rs.next()) {
> rs.getBlob(1);
> }
> If len < 32K there is no error.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4102) Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K

2009-11-10T02:02:28Z

[ https://issues.apache.org/jira/browse/DERBY-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775362#action_12775362 ]

Kristian Waagan commented on DERBY-4102:
----------------------------------------

Testing this patch again, I have observed an intermittent failure both with a clean trunk and with a patched trunk (patch DERBY-4102 1a).

Running with a sane build:
1) testBlobWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
at org.apache.derby.impl.store.raw.data.BasePage.unlatch(BasePage.java:1365)
at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:152)
at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
at java.io.DataInputStream.read(DataInputStream.java:132)
at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:116)
at org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
at org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:184)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

This associated code in BasePage is:
public void unlatch() {
if (SanityManager.DEBUG) {
SanityManager.ASSERT(isLatched());
}
releaseExclusive();
}

1) testBlobWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)java.io.IOException: ERROR 40XD0: Container has been closed.
at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:159)
at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
at java.io.DataInputStream.read(DataInputStream.java:132)
at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:116)
at org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
at org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:184)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

The origin of the real exception is lost here (not chained), and when I was about to investigate where it

The Java deadlock (see attached dump for details):

> Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K
> -----------------------------------------------------------------------------
>
> Key: DERBY-4102
> URL: https://issues.apache.org/jira/browse/DERBY-4102
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.1.0, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Kristian Waagan
> Attachments: CastExc.java, derby-4102-1a.diff, derby-4102-1a.stat
>
>
> The code below results in an assert error (with sane jars) or a ClassCastException (with insane jars):
> PreparedStatement ps = c.prepareStatement("values cast(? as blob)");
> int len = 32 * 1024;
> ps.setBinaryStream(1, new ByteArrayInputStream(new byte[len]), len);
> ResultSet rs = ps.executeQuery();
> while (rs.next()) {
> rs.getBlob(1);
> }
> If len < 32K there is no error.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Subscription: Derby: JIRA issues with patch available

2009-11-10T00:36:28Z

Issue Subscription
Filter: Derby: JIRA issues with patch available (12 issues)
Subscriber: derby-dev

Key Summary
DERBY-4436 Refactor existing in-memory back end tests and add new tests for dropping database
https://issues.apache.org/jira/browse/DERBY-4436
DERBY-4357 TableFunctions provide no information to limit underlying query
https://issues.apache.org/jira/browse/DERBY-4357
DERBY-4432 Memory leak when attempting to boot non-existing database with the in-memory back end
https://issues.apache.org/jira/browse/DERBY-4432
DERBY-4183 Our regression tests use various jar files for which we don't have build scripts.
https://issues.apache.org/jira/browse/DERBY-4183
DERBY-151 Thread termination -> XSDG after operation is 'complete'
https://issues.apache.org/jira/browse/DERBY-151
DERBY-1191 Some SQLExceptions, for example those generated from BrokeredStatements, do not print to derby.log even when derby.stream.error.logSeverityLevel=0
https://issues.apache.org/jira/browse/DERBY-1191
DERBY-4272 SQL Authorization Support for dblook
https://issues.apache.org/jira/browse/DERBY-4272
DERBY-873 OSGi bundle activator not JSR169 compliant
https://issues.apache.org/jira/browse/DERBY-873
DERBY-4137 OOM issue using XA with timeouts
https://issues.apache.org/jira/browse/DERBY-4137
DERBY-4102 Assert failure or ClassCastException in EmbedBlob when retrieving BLOB >= 32K
https://issues.apache.org/jira/browse/DERBY-4102
DERBY-3788 Provide a zero-admin way of updating the statisitcs of an index
https://issues.apache.org/jira/browse/DERBY-3788
DERBY-4241 Improve transition from read-only to writable Clob representation
https://issues.apache.org/jira/browse/DERBY-4241

You may edit this subscription at:
https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?subId=10396&filterId=12310751

[jira] Assigned: (DERBY-4190) Incorrect example for SYSCS_DIAG.CONTAINED_ROLES in the reference manual

2009-11-09T21:03:32Z

[ https://issues.apache.org/jira/browse/DERBY-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton reassigned DERBY-4190:
--------------------------------------

Assignee: Bryan Pendleton

> Incorrect example for SYSCS_DIAG.CONTAINED_ROLES in the reference manual
> ------------------------------------------------------------------------
>
> Key: DERBY-4190
> URL: https://issues.apache.org/jira/browse/DERBY-4190
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 10.5.1.1
> Reporter: Knut Anders Hatlen
> Assignee: Bryan Pendleton
> Priority: Minor
>
> The example for SYSCS_DIAG.CONTAINED_ROLES in the reference manual does not work.
> http://db.apache.org/derby/docs/dev/ref/rrefsyscsdiagtables.html
> The example looks like this:
> SELECT * FROM TABLE (SYSCS_DIAG.CONTAINED_ROLES(reader))
> There are two problems:
> 1) the table needs an alias (for instance, append AS T1), otherwise this error is raised:
> ERROR 42X01: Syntax error: Encountered "<EOF>" at line 1, column 56.
> Issue the 'help' command for general information on IJ command syntax.
> Any unrecognized commands are treated as potential SQL commands and executed directly.
> Consult your DBMS server reference documentation for details of the SQL syntax supported by your server.
> 2) the name of the role should be a string (needs single quotes), not an identifier, otherwise this error is raised:
> ERROR 42X04: Column 'READER' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'READER' is not a column in the target table.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-4253) documentation should indicate that a database cannot be upgraded if already booted in soft upgrade mode

2009-11-09T21:01:33Z

[ https://issues.apache.org/jira/browse/DERBY-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton reassigned DERBY-4253:
--------------------------------------

Assignee: Bryan Pendleton

> documentation should indicate that a database cannot be upgraded if already booted in soft upgrade mode
> -------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4253
> URL: https://issues.apache.org/jira/browse/DERBY-4253
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.6.0.0
> Reporter: Kathey Marsden
> Assignee: Bryan Pendleton
> Priority: Minor
>
> The documentation should indicate that you cannot perform a full upgrade on a database already booted in soft upgrade mode. If a database is already booted in soft upgrade mode, the upgrade=true attribute will have no effect. If a database is already booted in soft upgrade mode, you can shutdown the database with the shutdown=true attribute and then connect with upgrade=true to perform the upgrade.
> Perhaps a good place for this might be at:
> http://db.apache.org/derby/docs/10.4/ref/rrefattribupgrade.html
> See the derby-user thread:
> http://www.nabble.com/Hard-upgrade-failing--td23826558.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-4107) The Reference Guide incorrectly describes the behavior of the DATE function when applied to an integer argument

2009-11-09T18:33:32Z

[ https://issues.apache.org/jira/browse/DERBY-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton resolved DERBY-4107.
------------------------------------

Resolution: Fixed
Fix Version/s: 10.6.0.0

Committed the change to the docs trunk as revision 834310.

> The Reference Guide incorrectly describes the behavior of the DATE function when applied to an integer argument
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4107
> URL: https://issues.apache.org/jira/browse/DERBY-4107
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 10.4.2.0
> Environment: MS Windows XP Professional Version 2002 Service Pack 2, running NetBeans IDE 6.5
> Reporter: Nelson Rodrigues
> Assignee: Bryan Pendleton
> Fix For: 10.6.0.0
>
> Attachments: docs.diff, rrefdatefunc.html
>
>
> When Derby Reference Manual, version 10.4, lists Derby limitations for DATE is said that the smallest DATE value is 0001-01-01 and the largest DATE value is 9999-12-31.
> When the same manual explains the DATE function is said that:
> "The argument must be ... a positive number less than or equal to 2,932,897 ... The result is the date that is n-1 days after January 1, 0001, where n is the integral part of the number."
> Testing for the largest integer returns the expected result:
> select date(2932897) from SYSIBM.SYSDUMMY1 returns 9999-12-31 -> OK
> The problem comes when testing the smallest integer. We get a result different than we expect:
> select date(1) from SYSIBM.SYSDUMMY1 returns 1970-01-01, but it should have returned 0001-01-01
> The smallest date we get using integer as an argument to date function should be the same we get when using the smallest string representation as an argument. In other words date(1) should be equal to date('0001-01-01').
> select date('0001-01-01') from SYSIBM.SYSDUMMY1 returns 0001-01-01 -> OK

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-4106) The Reference Gulde claims that the INTEGER function can be applied to dates and times

2009-11-09T18:07:32Z

[ https://issues.apache.org/jira/browse/DERBY-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton resolved DERBY-4106.
------------------------------------

Resolution: Fixed
Fix Version/s: 10.6.0.0

Commited to the documentation trunk as revision 834300.

> The Reference Gulde claims that the INTEGER function can be applied to dates and times
> --------------------------------------------------------------------------------------
>
> Key: DERBY-4106
> URL: https://issues.apache.org/jira/browse/DERBY-4106
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 10.4.2.0
> Environment: MS Windows XP Professional Version 2002 Service Pack 2, running NetBeans IDE 6.5
> Reporter: Nelson Rodrigues
> Assignee: Bryan Pendleton
> Fix For: 10.6.0.0
>
> Attachments: docs.diff, rrefbuiltinteger.html
>
>
> When Derby Reference Manual, version 10.4, explains the INTEGER function is said that:
> "The INTEGER function returns an integer representation of a number, character string,
> DATE, or time in the form of an integer constant"
> But when I try to convert a DATE to INTEGER I receive an sqlstate 42846: "Cannot convert types 'DATE' to 'INTEGER'."
> This is a sample query where the expected result is the integer number 1:
> select integer(date(1)) from SYSIBM.SYSDUMMY1

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-858) ijConnName test output order is non-deterministic.

2009-11-09T14:47:32Z

[ https://issues.apache.org/jira/browse/DERBY-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775178#action_12775178 ]

Myrna van Lunteren commented on DERBY-858:
------------------------------------------

ij5.sql has the same problem.
If the hash table ordering is different, this may result in ConnTwo being the first connection made, and so the active connection.

I think it's ok for these two tests to not have the 2nd valid pre-defined connection. Does anyone disagree?

> ijConnName test output order is non-deterministic.
> --------------------------------------------------
>
> Key: DERBY-858
> URL: https://issues.apache.org/jira/browse/DERBY-858
> Project: Derby
> Issue Type: Bug
> Components: Test
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> The test loads four initial connections using these ij.connection properties in the test's _app.properties file.
> ij.connection.connOne=jdbc:derby:wombat;create=true
> ij.connection.connTwo=jdbc:derby:lemming;create=true
> ij.connection.connThree=jdbc:noone:fruitfly;create=true
> ij.connection.connFour=jdbc:derby:nevercreated
> The order these connections are created, and hence the order of the test output is only determined by the hash table ordering of the properties file. Making small changes in ijConnName_app.properties files can change the order, making the test appear to fail.
> E.g. I tried to enable the test with a security manager by modifying the noSecurityManger to be set to false, and the order changed.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-1465) NetworkServerControl.start() should throw an exception and not just print exceptions if the server fails to start

2009-11-09T11:57:32Z

[ https://issues.apache.org/jira/browse/DERBY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren closed DERBY-1465.
-------------------------------------

Resolution: Won't Fix

Closing as won't fix after reporter's reconsidering.

> NetworkServerControl.start() should throw an exception and not just print exceptions if the server fails to start
> --------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1465
> URL: https://issues.apache.org/jira/browse/DERBY-1465
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assignee: Myrna van Lunteren
> Priority: Minor
> Attachments: DERBY-1465.diff3, DERBY-1465.diff4, DERBY-1465.diff5, DERBY-1465.diff6, DERBY-1465.diff7, DERBY-1465.diff8, DERBY-1465_diff.txt, DERBY-1465_diff.txt, DERBY-1465_stat.txt, DERBY-1465_stat.txt, DERBY-1465hangibm142_12_29_08.txt, DERBY-1465hangibm15_12_29_08.txt, releaseNote.html, releaseNote.html, releaseNote.html
>
>
> NetworkServerControl.start() will not throw an exception if another server is already running on the same port. I am not sure but think perhaps this was changed at one point to accomodate the derby.drda.startNetworkServer property so that the embedded server could continue to boot even if the network server failed to start, but I think this is wrong for normal usage.
> http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Blocking new connection requests in Derby

2009-11-09T11:47:38Z

Thanks for writing up this spec, Kristian. If I understand correctly,
you are proposing a mechanism for rejecting new connections to a
database to handle the following situations:

1) Eliminate race conditions and ugly, puzzling diagnostic messages
during database shutdown and database deletion.

2) Protect extended database maintenance from corrupting, concurrent access.

It seems to me that (1) is a very reasonable use case and probably
doesn't need any additional api: by default a database shutdown/deletion
should prevent other users from connecting and should, in fact, kick out
all other users.

Can you give some use-cases for situation (2)?

Thanks,
-Rick

Kristian Waagan wrote:

> Hello,
>
> When working on the feature of dropping databases (in-memory
> primarily), it became apparent that the possibility to temporarily
> block incoming connection attempts would be very useful.
>
> I have started on a spec for this feature. Today I was supposed to
> continue working on it, but got lost in code trying to write a
> prototype to verify some claims instead :)
> I'm choosing to post it now anyway to see if I get any feedback on
> whether this feature would be useful in other scenarios. If so, there
> may be new requirements not included in the current spec.
> Verification of what I have written about authentication and
> authorization is also definitely required.
>
> If I get positive feedback, I can create a Jira and post a prototype
> shortly after. This should allow us to make progress after our initial
> discussion here. If you want to have a quick look at the test I threw
> at Derby (currently doesn't work because all the required code hasn't
> been posted, specifically the drop database code), see the class
> DropWhileConnectingTest in patch 1a attached to DERBY-4436.
>
>
> As a side note, most of my work so far has been with the embedded
> driver. I suspect getting the network client to behave as well as the
> embedded driver may be harder.
>
>
> Regards,

[jira] Commented: (DERBY-4439) NullPointerException at bind time when selecting from VALUES NULL

2009-11-09T11:47:32Z

[ https://issues.apache.org/jira/browse/DERBY-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775094#action_12775094 ]

Mamta A. Satoor commented on DERBY-4439:
----------------------------------------

Another thing that can be pursued is to see if genSQLJavaSQLTree() can be called after all the binding is finished(including the untyped nulls).

> NullPointerException at bind time when selecting from VALUES NULL
> -----------------------------------------------------------------
>
> Key: DERBY-4439
> URL: https://issues.apache.org/jira/browse/DERBY-4439
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
>
> I see a NullPointerException when I try the following query:
> ij> select x*2 from (values null) v(x);
> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> It should fail gracefully instead, like this similar query:
> ij> select x from (values null) v(x);
> ERROR 42X07: Null is only allowed in a VALUES clause within an INSERT statement.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4439) NullPointerException at bind time when selecting from VALUES NULL

2009-11-09T11:13:32Z

[ https://issues.apache.org/jira/browse/DERBY-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775081#action_12775081 ]

Mamta A. Satoor commented on DERBY-4439:
----------------------------------------

I looked through the code and experimented with some changes. Basically, during the bind phase, CursorNode does binding in following order
super.bind(dataDictionary);

// bind the query expression
resultSet.bindResultColumns(fromList);

// this rejects any untyped nulls in the select list
// pass in null to indicate that we don't have any
// types for this node
resultSet.bindUntypedNullsToResultColumns(null);
In other words, untyped nulls are bound at the end.

In case of our query, where we are using a binary operator node, while we are going through the resultSet.bindResultColumns(fromList) code in CursorNode, we call BinaryOperatorNode.bindExpression() and towards the end of this method, there is following call
return genSQLJavaSQLTree();
This piece of code assumes that everything is bound by now but since call to untyped nulls has not been made, we run into NPE.

I tried putting in call to binding untyped nulls in FromSubquery.bindExpression and that fixed the query in question but that is not the right thing to do exactly. For following query, with my changes, we end up throwing exception that Null is only allowed in a VALUES clause within an INSERT statement.
create table u (c1 integer);
insert into u select * from (values null) as X;
We need to be able to differentiate the fact that we are dealing with a CursorNode at the top and hence only for that case, we should try to bind untyped nulls. I will work on this more. If anyone has any suggestions on a fix, please share them here

> NullPointerException at bind time when selecting from VALUES NULL
> -----------------------------------------------------------------
>
> Key: DERBY-4439
> URL: https://issues.apache.org/jira/browse/DERBY-4439
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
>
> I see a NullPointerException when I try the following query:
> ij> select x*2 from (values null) v(x);
> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> It should fail gracefully instead, like this similar query:
> ij> select x from (values null) v(x);
> ERROR 42X07: Null is only allowed in a VALUES clause within an INSERT statement.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Regression Test Report - Daily 833891 - Sun DBTG

2009-11-09T08:55:46Z

[Auto-generated mail]

*Daily* 833891/2009-11-08 18:01:26 MET

Failed Tests OK Skip Duration Suite
-------------------------------------------------------
*Jvm: 1.6*
lin
0 11702 11702 0 1008.75% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 54.38% derbyall
0 2 2 0 457.42% compatibility
0 2 2 0 .% demoSuite
sles
0 11702 11702 0 692.10% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 49.55% derbyall
0 2 2 0 188.96% compatibility
0 2 2 0 .% demoSuite
sol
0 11702 11702 0 817.67% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 41.45% derbyall
0 2 2 0 282.59% compatibility
0 2 2 0 .% demoSuite
solN+1
0 11702 11702 0 139.93% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 66.99% derbyall
0 2 2 0 272.15% compatibility
0 2 2 0 .% demoSuite
sparc
0 11702 11702 0 526.79% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 47.29% derbyall
0 2 2 0 263.18% compatibility
0 2 2 0 .% demoSuite
vista
0 9770 9770 0 114.81% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 58.90% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
vista-64
0 11696 11696 0 188.44% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 57.95% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
w2003
0 11696 11696 0 230.11% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 70.18% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-833891.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/833891_bySig.html

*Jvm: 1.5*
lin
0 222 222 0 51.30% derbyall
0 9912 9912 0 1706.27% suitesAll
sles
0 222 222 0 45.93% derbyall
0 9912 9912 0 1088.86% suitesAll
sol
0 222 222 0 45.30% derbyall
0 9912 9912 0 1514.25% suitesAll
solN+1
0 222 222 0 60.12% derbyall
0 9912 9912 0 1408.78% suitesAll
sparc
0 222 222 0 47.57% derbyall
0 9912 9912 0 1216.15% suitesAll
vista
0 222 222 0 44.66% derbyall
0 9906 9906 0 911.25% suitesAll
vista-64
0 222 222 0 58.30% derbyall
0 9906 9906 0 212.47% suitesAll
w2003
0 222 222 0 54.93% derbyall
0 9906 9906 0 568.64% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-833891.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/FailReports/833891_bySig.html

*Jvm: 1.4*
lin
0 219 219 2 51.48% derbyall
0 9759 9759 0 1534.59% suitesAll
sles
0 219 219 2 43.16% derbyall
0 9759 9759 0 913.05% suitesAll
sol
0 219 219 2 42.51% derbyall
0 9759 9759 0 1226.78% suitesAll
solN+1
0 219 219 2 58.75% derbyall
0 9759 9759 0 1315.17% suitesAll
sparc
0 219 219 2 47.25% derbyall
0 9759 9759 0 1227.48% suitesAll
vista
0 219 219 2 44.52% derbyall
0 9753 9753 0 896.61% suitesAll
vista-64
0 219 219 2 57.11% derbyall
0 9753 9753 0 216.52% suitesAll
w2003
0 219 219 2 57.09% derbyall
0 9759 9759 0 568.16% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-833891.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/FailReports/833891_bySig.html

.......................................................
*Jvm: 1.7*
lin
0 11702 11702 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
0 2 2 0 .% compatibility
0 2 2 0 .% demoSuite
sol
0 11702 11702 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
0 2 2 0 .% compatibility
0 2 2 0 .% demoSuite
vista-64
0 11696 11696 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-833891.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/833891_bySig.html

*Jvm: phoneME*
ubuntu
0 4410 4410 0 .% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/javaME/testing/Limited/testSummary-833891.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/javaME/FailReports/833891_bySig.html

-------------------------------------------------------

Changes in http://dbtg.foundry.sun.com/derby/test/Daily/UpdateInfo/833891.txt

( All results in http://dbtg.foundry.sun.com/derby/test/ )