date:20080227

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

Kristian Waagan updated DERBY-3441:
---

Attachment: derby-3441-2a-minor_am_refactoring.diff

Thanks for the comment Dan. I'll address your other comments later.

'derby-3441-2a-minor_am_refactoring.diff' addresses Dans comment about the
improvement in resetParameters. I changed this (and other existing code) to use
Arrays.fill, and also removed some unnecessary throws clauses from the existing
code. I figured out 'batch_' was never set to null, so I made it final and
removed a null check.

In the future it might be better to only create the ArrayList if you actually
do batching, and maybe add a clearBatchX method that will be called where
batch_.clear is called currently.

Committed patch 2a to trunk with revision 631515.
Have run a subset of the regression tests, am running the full suite for
verification.

Determine and implement a proper procedure for resetting a prepared statement
for reuse in a statement pool
---

Key: DERBY-3441
URL: https://issues.apache.org/jira/browse/DERBY-3441
Project: Derby
Issue Type: Sub-task
Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Fix For: 10.4.0.0

Attachments: derby-3441-1a-statement_reset.diff,
derby-3441-2a-minor_am_refactoring.diff

Initial investigations indicate there are no existing suitable methods to
properly reset a prepared (or callable) statement for reuse with a statement
pool.
A full reset is too heavy weight and defeats the purpose of statement
pooling, but a proper procedure should be achievable by reusing existing
pieces of code.
Correctness is of course the most important thing.

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

[jira] Updated: (DERBY-3364) Replication failover implementation must be modified to fail at the master after slave has been stopped


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

Øystein Grøvlen updated DERBY-3364:
---

Derby Info:   (was: [Patch Available])

Committed the v3 patch as revision 631534. Thanks, Narayanan for the fix.

 Replication failover implementation must be modified to fail at the master 
 after slave has been stopped
 ---

 Key: DERBY-3364
 URL: https://issues.apache.org/jira/browse/DERBY-3364
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: Derby3364_v1.diff, Derby3364_v1.stat, Derby3364_v2.diff, 
 Derby3364_v2.stat, Derby3364_v3.diff, Derby3364_v3.stat


 Jorgen says...
 I tried to run the failover command on the master, which seems to work fine 
 as long as the master and slave are still connected. If the slave has been 
 stopped for some reason, however, failover hangs on 
 MasterController#startFailover here: 
 ack = transmitter.readMessage();

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

[jira] Updated: (DERBY-3455) Move replication methods from org.apache.derby.database.Database to org.apache.derby.iapi.db.Database


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

Øystein Grøvlen updated DERBY-3455:
---

Derby Info:   (was: [Patch Available])

Committed patch, Derby3455_v2.diff, as revision 631527.

I hope there will be a follow-up patch that unwraps the SQLExcpetions into
StandardException for these methods.

 Move replication methods from org.apache.derby.database.Database to 
 org.apache.derby.iapi.db.Database
 -

 Key: DERBY-3455
 URL: https://issues.apache.org/jira/browse/DERBY-3455
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: Derby3455.diff, Derby3455.stat, Derby3455_v2.diff, 
 Derby3455_v2.stat




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

[jira] Commented: (DERBY-3455) Move replication methods from org.apache.derby.database.Database to org.apache.derby.iapi.db.Database


[ 
https://issues.apache.org/jira/browse/DERBY-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572850#action_12572850
 ] 

V.Narayanan commented on DERBY-3455:



Thank you for the review and commit Oystein.


I will submit a follow-up patch for this issue!



 Move replication methods from org.apache.derby.database.Database to 
 org.apache.derby.iapi.db.Database
 -

 Key: DERBY-3455
 URL: https://issues.apache.org/jira/browse/DERBY-3455
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: Derby3455.diff, Derby3455.stat, Derby3455_v2.diff, 
 Derby3455_v2.stat




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

[jira] Commented: (DERBY-3364) Replication failover implementation must be modified to fail at the master after slave has been stopped


[ 
https://issues.apache.org/jira/browse/DERBY-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572851#action_12572851
 ] 

Øystein Grøvlen commented on DERBY-3364:


I have tested that patch v3 fixes the reported problem, and the patch looks 
good so I will commit it.

However, I think there is still a case in MasterController where 
teardownNetwork() needs to be called:
If the call to flushBuffer in stopMaster fails, teardownNetwork() is not 
called.  Is this covered by another JIRA?

 Replication failover implementation must be modified to fail at the master 
 after slave has been stopped
 ---

 Key: DERBY-3364
 URL: https://issues.apache.org/jira/browse/DERBY-3364
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: Derby3364_v1.diff, Derby3364_v1.stat, Derby3364_v2.diff, 
 Derby3364_v2.stat, Derby3364_v3.diff, Derby3364_v3.stat


 Jorgen says...
 I tried to run the failover command on the master, which seems to work fine 
 as long as the master and slave are still connected. If the slave has been 
 stopped for some reason, however, failover hangs on 
 MasterController#startFailover here: 
 ack = transmitter.readMessage();

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

[jira] Created: (DERBY-3471) Report meaningful error message when trying to use a connection to a database that has been shutdown

Report meaningful error message when trying to use a connection to a database 
that has been shutdown


 Key: DERBY-3471
 URL: https://issues.apache.org/jira/browse/DERBY-3471
 Project: Derby
  Issue Type: Improvement
Reporter: Jørgen Løland


If you try to use a connection to a database that has been shutdown, you get 
the following error message:

ERROR 08006: A network protocol error was encountered and the connection has 
been terminated: the requested command encountered an unarchitected and 
implementation-specific condition for which there was no architected message

The error message should say that the database has been shut down.

Repro:

term1: start NS
term2: ij connect 'jdbc:derby://localhost/test';
term3: ij connect 'jdbc:derby://localhost/test;shutdown=true'
term2: ij show tables
ERROR 08006: A network protocol error was encountered and the connection has 
been terminated: the requested command encountered an unarchitected and 
implementation-specific condition for which there was no architected message


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

[jira] Commented: (DERBY-3428) Doing a replication failover should shutdown the database and the connection should no longer be available


[ 
https://issues.apache.org/jira/browse/DERBY-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572852#action_12572852
 ] 

Jørgen Løland commented on DERBY-3428:
--

I tried the following:

---8
term1: start NS
term2: boot database '//localhost/test'
term3: shutdown '//localhost/test'
term2: show tables

ERROR 08006: A network protocol error was encountered and the connection has 
been terminated: the requested command encountered an unarchitected and 
implementation-specific condition for which there was no architected message
---8--

Hence, this is the message you get when you try to do something with a 
connection to a database that has been closed. It is not replication-specific. 
I'll open a new jira for this.


 Doing a replication failover should shutdown the database and the connection 
 should no longer be available
 --

 Key: DERBY-3428
 URL: https://issues.apache.org/jira/browse/DERBY-3428
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: Derby3428.diff, Derby3428.stat, Derby3428_v1.diff, 
 Derby3428_v1.stat


 Oystein says (as part of comments in Derby-3205)
 After executing a failover, I am told that the database is shut down, but I 
 still able to use the connection to access the database:
 ij version 10.4
 ij connect 'jdbc:derby:masterDB;user=oystein;password=pass';
 ij call syscs_util.syscs_freeze_database();
 0 rows inserted/updated/deleted
 ij connect 
 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost';
 ij(CONNECTION1) call syscs_util.syscs_unfreeze_database();
 0 rows inserted/updated/deleted
 ij(CONNECTION1) connect 
 'jdbc:derby:masterDB;user=oystein;password=pass;failover=true';
 ERROR XRE20: Failover performed successfully for database 'null', the 
 database has been shutdown.
 ij(CONNECTION1) select * from t;
 I
 ---
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 10
 11 rows selected
 ij(CONNECTION1)

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

[jira] Commented: (DERBY-3470) Replication: Master never gives up when slave dies.


[ 
https://issues.apache.org/jira/browse/DERBY-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572861#action_12572861
 ] 

Øystein Grøvlen commented on DERBY-3470:


Forgot to mention that when I tried to exit the ij which embedded the master, a 
hang occurred.

 Replication: Master never gives up when slave dies.
 ---

 Key: DERBY-3470
 URL: https://issues.apache.org/jira/browse/DERBY-3470
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: Øystein Grøvlen

 After starting replication, I killed the slave process.  The master continued 
 to write 
  Replication master role stopped for database 'masterDB'.
   BEGIN REPLICATION ERROR MESSAGE -
 Exception occurred during log shipping.
 java.net.SocketException: Broken pipe
 ...
 over and over again.  Soon my derby.log was several gigabytes.
 In this scenario I inserted a lot of data, assuming that the
 replication would stop when the database buffer became full, after
 inserting more than 100 MB, the error messages still appeared.

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

[jira] Updated: (DERBY-3360) Invalid method java.lang.Integer void init(short) because java.lang.NoSuchMethodException: java.lang.Integer.init(short)

2008-02-27 Thread James Alan Shepherd (JIRA)


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

James Alan Shepherd updated DERBY-3360:
---

Attachment: DERBY-3360-cast.tar.gz

Test case attached

Running against 10.3.2.1 sane:

ij version 10.3
CONNECTION0* -  jdbc:derby:testcase
* = current connection
ij CREATE FUNCTION FN_SMALLINT(i INT) RETURNS SMALLINT PARAMETER STYLE JAVA NO 
SQL LANGUAGE JAVA EXTERNAL NAME 'Functions.smallint' RETURNS NULL ON NULL INPUT;
0 rows inserted/updated/deleted
ij CREATE TABLE test (a INT);
0 rows inserted/updated/deleted
ij INSERT INTO test VALUES (1),(2),(3),(4),(5);
5 rows inserted/updated/deleted
ij SELECT a FROM test WHERE FN_SMALLINT(a)  1;
java.lang.NoSuchMethodException: java.lang.Integer.init(short)
at java.lang.Class.getConstructor0(Class.java:2706)
at java.lang.Class.getConstructor(Class.java:1657)
at 
org.apache.derby.impl.services.bytecode.d_BCValidate.checkMethod(d_BCValidate.java:116)
at 
org.apache.derby.impl.services.bytecode.BCMethod.callMethod(BCMethod.java:745)
at 
org.apache.derby.impl.services.bytecode.BCMethod.pushNewComplete(BCMethod.java:779)
at 
org.apache.derby.impl.sql.compile.StaticMethodCallNode.generateExpression(StaticMethodCallNode.java:995)
at 
org.apache.derby.impl.sql.compile.JavaToSQLValueNode.generateExpression(JavaToSQLValueNode.java:167)
at 
org.apache.derby.impl.sql.compile.BinaryOperatorNode.generateExpression(BinaryOperatorNode.java:599)
at 
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1484)
at 
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1302)
at 
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1351)
at 
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1302)
at 
org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(ScrollInsensitiveResultSetNode.java:109)
at 
org.apache.derby.impl.sql.compile.CursorNode.generate(CursorNode.java:564)
at 
org.apache.derby.impl.sql.compile.StatementNode.generate(StatementNode.java:347)
at 
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:447)
at 
org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:746)
at 
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:579)
at 
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:528)
at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:330)
at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:522)
at 
org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:364)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:262)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56)
at org.apache.derby.tools.ij.main(ij.java:71)
Invalid method java.lang.Integer  void init(short) because 
java.lang.NoSuchMethodException: java.lang.Integer.init(short)
ERROR XJ001: Java exception: 'ASSERT FAILED Invalid method java.lang.Integer  
void init(short) because java.lang.NoSuchMethodException: 
java.lang.Integer.init(short): 
org.apache.derby.shared.common.sanity.AssertFailure'.

 Invalid method java.lang.Integer  void init(short) because 
 java.lang.NoSuchMethodException: java.lang.Integer.init(short)
 ---

 Key: DERBY-3360
 URL: https://issues.apache.org/jira/browse/DERBY-3360
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.2.1, 10.3.2.2
 Environment: Derby 10.3 Branch [10.3.2.2 - (616244M)] and 10.3.2.1
 java version 1.6.0_03
 Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
 Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)
Reporter: James Alan Shepherd
 Attachments: DERBY-3360-cast.tar.gz


 Invalid method java.lang.Integer  void init(short) because 
 java.lang.NoSuchMethodException: java.lang.Integer.init(short)
 True, but I believe, not a helpful observation :-)
 FN_MATCHES(A.f, C.d) returns short/SMALLINT
 related to DERBY-3310 ? But this is on the 10.3 branch [10.3.2.2 - (616244M)]
 DEBUG 68421 [Main] (Template.java:69) - SQL: SELECT A.a, D.b, B.c, C.d FROM C 
 JOIN A ON C.e = 'I' AND A.f IS NOT NULL AND A.g = C.g AND FN_MATCHES(A.f, 
 C.d)  1 JOIN B ON B.h = A.g JOIN D ON D.h =

[jira] Created: (DERBY-3472) Replication: Thread deadlock when deleting many records.

Replication: Thread deadlock when deleting many records.


 Key: DERBY-3472
 URL: https://issues.apache.org/jira/browse/DERBY-3472
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Derby trunk revision 631534 + DERBY 3205 patch 
failover-slave-2a.
Reporter: Øystein Grøvlen


When I tried to delete ca 28 records from a table while replication was 
running, the statement never completed.
VisualVM reports a deadlock:

Found one Java-level deadlock:
=
Thread-2:
  waiting to lock monitor 0x08164e4c (object 0xfa9db5f8, a java.lang.Object),
  which is held by main
main:
  waiting to lock monitor 0x08164d20 (object 0xfa9db608, a 
org.apache.derby.impl.services.replication.master.AsynchronousLogShipper),
  which is held by Thread-2

Java stack information for the threads listed above:
===
Thread-2:
at 
org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.next(ReplicationLogBuffer.java:182)
- waiting to lock 0xfa9db5f8 (a java.lang.Object)
at 
org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.shipALogChunk(AsynchronousLogShipper.java:218)
- locked 0xfa9db608 (a 
org.apache.derby.impl.services.replication.master.AsynchronousLogShipper)
at 
org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.run(AsynchronousLogShipper.java:169)
main:
at 
org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.workToDo(AsynchronousLogShipper.java:336)
- waiting to lock 0xfa9db608 (a 
org.apache.derby.impl.services.replication.master.AsynchronousLogShipper)
at 
org.apache.derby.impl.services.replication.master.MasterController.workToDo(MasterController.java:472)
at 
org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.switchDirtyBuffer(ReplicationLogBuffer.java:322)
at 
org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.appendLog(ReplicationLogBuffer.java:148)
- locked 0xfa9db5f8 (a java.lang.Object)
at 
org.apache.derby.impl.services.replication.master.MasterController.appendLog(MasterController.java:328)
at 
org.apache.derby.impl.store.raw.log.LogAccessFile.writeToLog(LogAccessFile.java:787)
- locked 0xbb041788 (a org.apache.derby.impl.io.DirRandomAccessFile4)
at 
org.apache.derby.impl.store.raw.log.LogAccessFile.flushDirtyBuffers(LogAccessFile.java:534)
at 
org.apache.derby.impl.store.raw.log.LogAccessFile.switchLogBuffer(LogAccessFile.java:611)
- locked 0xbb041618 (a 
org.apache.derby.impl.store.raw.log.LogAccessFile)
at 
org.apache.derby.impl.store.raw.log.LogAccessFile.reserveSpaceForChecksum(LogAccessFile.java:855)
at 
org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3737)
- locked 0xbb041528 (a org.apache.derby.impl.store.raw.log.LogToFile)
at 
org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:370)
- locked 0xfab06ec8 (a org.apache.derby.impl.store.raw.log.FileLogger)
at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1193)
at 
org.apache.derby.impl.store.raw.data.LoggableActions.doAction(LoggableActions.java:221)
at 
org.apache.derby.impl.store.raw.data.LoggableActions.actionDelete(LoggableActions.java:64)
at 
org.apache.derby.impl.store.raw.data.BasePage.deleteAtSlot(BasePage.java:1149)
at 
org.apache.derby.impl.store.access.btree.BTreeScan.delete(BTreeScan.java:1386)
at 
org.apache.derby.impl.sql.execute.IndexChanger.doDelete(IndexChanger.java:369)
at 
org.apache.derby.impl.sql.execute.IndexChanger.delete(IndexChanger.java:544)
at 
org.apache.derby.impl.sql.execute.IndexSetChanger.delete(IndexSetChanger.java:250)
at 
org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(RowChangerImpl.java:476)
at 
org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(DeleteResultSet.java:405)
at 
org.apache.derby.impl.sql.execute.DeleteResultSet.open(DeleteResultSet.java:137)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:372)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1234)
- locked 0xfab36948 (a org.apache.derby.impl.jdbc.EmbedConnection40)
at 
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:624)
- locked 0xfab36948 (a org.apache.derby.impl.jdbc.EmbedConnection40)
at 
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:556)
at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:330)
at

[jira] Commented: (DERBY-3205) Replication: Add connection url command options for starting, stopping slave and for failover


[ 
https://issues.apache.org/jira/browse/DERBY-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572876#action_12572876
 ] 

Øystein Grøvlen commented on DERBY-3205:


DERBY-3472 illustrates the concern I have with the current limitation on 
slave-initiated failover.
A thread deadlock occurs on the master, but the slave is not allowed to do 
failover because the connection to the master is still up.


 Replication: Add connection url command options for starting, stopping slave 
 and for failover
 -

 Key: DERBY-3205
 URL: https://issues.apache.org/jira/browse/DERBY-3205
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: Jørgen Løland
 Attachments: derby-3205_startslave_dontcommit.diff, 
 derby-3205_startslave_dontcommit.stat, failover-slave-1a.diff, 
 failover-slave-1a.stat, failover-slave-2a.diff, failover-slave-2a.stat, 
 failover_impl_3205_NotForCommit_v1.diff, 
 failover_impl_3205_NotForCommit_v1.stat, failover_impl_3205_v1.diff, 
 failover_impl_3205_v1.stat, failover_impl_3205_v2.diff, 
 failover_impl_3205_v2.stat, failover_impl_3205_v3.diff, 
 failover_impl_3205_v3.stat, failover_impl_3205_v4.diff, 
 failover_impl_3205_v4.stat, Socket_Close_Fix_v1.diff, 
 Socket_Close_Fix_v1.stat, startSlave_1a.diff, startSlave_1a.stat, 
 startSlave_1b.diff, startSlave_1b.stat, startSlave_1c.diff, 
 startSlave_1d.diff, StopSlave_impl_3205_NotForCommit_v1.diff, 
 StopSlave_impl_3205_NotForCommit_v1.stat, stopSlave_v1a.diff, 
 stopSlave_v1a.stat, stopSlave_v1b.diff, stopSlave_v1b.stat, 
 stopSlave_v1c.diff, stopSlave_v1c.stat


 Add commands to start and stop the replication slave using properties or 
 connection url. Example:
 'jdbc:derby:hostdbname;startSlave=true';
 'jdbc:derby:hostdbname;stopSlave=true';
 'jdbc:derby:hostdbname;failover=true;
 Connection url options that must be recognized:
 startSlave=true
 stopSlave=true
 failover=true
 slaveHost=host (optional, defaults to localhost) (only for startSlave)
 slavePort=port (optional, defaults to 8001) (only for startSlave)
 See functional specification on Derby-2872 for further details.

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

[jira] Created: (DERBY-3474) update unique constraint sections of refrence manual

update unique constraint sections of refrence manual


 Key: DERBY-3474
 URL: https://issues.apache.org/jira/browse/DERBY-3474
 Project: Derby
  Issue Type: Sub-task
Affects Versions: 10.4.0.0
Reporter: Anurag Shekhar


Derby-3330 adds support for unique constraint over null able fields. Derby 
refrence manual should be updated to include it while explaining about unique 
constraint.

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

[jira] Updated: (DERBY-3474) update unique constraint sections of refrence manual


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

Anurag Shekhar updated DERBY-3474:
--

Attachment: derby-3474.diff

I have updated relevant sections of dita sources to include changes about 
unique constraint over null able fields. These changes can be used only as 
starting point for manual changes. 

 update unique constraint sections of refrence manual
 

 Key: DERBY-3474
 URL: https://issues.apache.org/jira/browse/DERBY-3474
 Project: Derby
  Issue Type: Sub-task
Affects Versions: 10.4.0.0
Reporter: Anurag Shekhar
 Attachments: derby-3474.diff


 Derby-3330 adds support for unique constraint over null able fields. Derby 
 refrence manual should be updated to include it while explaining about unique 
 constraint.

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

[jira] Created: (DERBY-3473) write test cases to test locking during tree operation

write test cases to test locking during tree operation
--

 Key: DERBY-3473
 URL: https://issues.apache.org/jira/browse/DERBY-3473
 Project: Derby
  Issue Type: Sub-task
Affects Versions: 10.4.0.0
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Priority: Minor




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

[jira] Assigned: (DERBY-3472) Replication: Thread deadlock when deleting many records.


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

Jørgen Løland reassigned DERBY-3472:


Assignee: Jørgen Løland

 Replication: Thread deadlock when deleting many records.
 

 Key: DERBY-3472
 URL: https://issues.apache.org/jira/browse/DERBY-3472
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Derby trunk revision 631534 + DERBY 3205 patch 
 failover-slave-2a.
Reporter: Øystein Grøvlen
Assignee: Jørgen Løland

 When I tried to delete ca 28 records from a table while replication was 
 running, the statement never completed.
 VisualVM reports a deadlock:
 Found one Java-level deadlock:
 =
 Thread-2:
   waiting to lock monitor 0x08164e4c (object 0xfa9db5f8, a java.lang.Object),
   which is held by main
 main:
   waiting to lock monitor 0x08164d20 (object 0xfa9db608, a 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper),
   which is held by Thread-2
 Java stack information for the threads listed above:
 ===
 Thread-2:
   at 
 org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.next(ReplicationLogBuffer.java:182)
   - waiting to lock 0xfa9db5f8 (a java.lang.Object)
   at 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.shipALogChunk(AsynchronousLogShipper.java:218)
   - locked 0xfa9db608 (a 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper)
   at 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.run(AsynchronousLogShipper.java:169)
 main:
   at 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.workToDo(AsynchronousLogShipper.java:336)
   - waiting to lock 0xfa9db608 (a 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper)
   at 
 org.apache.derby.impl.services.replication.master.MasterController.workToDo(MasterController.java:472)
   at 
 org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.switchDirtyBuffer(ReplicationLogBuffer.java:322)
   at 
 org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.appendLog(ReplicationLogBuffer.java:148)
   - locked 0xfa9db5f8 (a java.lang.Object)
   at 
 org.apache.derby.impl.services.replication.master.MasterController.appendLog(MasterController.java:328)
   at 
 org.apache.derby.impl.store.raw.log.LogAccessFile.writeToLog(LogAccessFile.java:787)
   - locked 0xbb041788 (a org.apache.derby.impl.io.DirRandomAccessFile4)
   at 
 org.apache.derby.impl.store.raw.log.LogAccessFile.flushDirtyBuffers(LogAccessFile.java:534)
   at 
 org.apache.derby.impl.store.raw.log.LogAccessFile.switchLogBuffer(LogAccessFile.java:611)
   - locked 0xbb041618 (a 
 org.apache.derby.impl.store.raw.log.LogAccessFile)
   at 
 org.apache.derby.impl.store.raw.log.LogAccessFile.reserveSpaceForChecksum(LogAccessFile.java:855)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3737)
   - locked 0xbb041528 (a org.apache.derby.impl.store.raw.log.LogToFile)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:370)
   - locked 0xfab06ec8 (a org.apache.derby.impl.store.raw.log.FileLogger)
   at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1193)
   at 
 org.apache.derby.impl.store.raw.data.LoggableActions.doAction(LoggableActions.java:221)
   at 
 org.apache.derby.impl.store.raw.data.LoggableActions.actionDelete(LoggableActions.java:64)
   at 
 org.apache.derby.impl.store.raw.data.BasePage.deleteAtSlot(BasePage.java:1149)
   at 
 org.apache.derby.impl.store.access.btree.BTreeScan.delete(BTreeScan.java:1386)
   at 
 org.apache.derby.impl.sql.execute.IndexChanger.doDelete(IndexChanger.java:369)
   at 
 org.apache.derby.impl.sql.execute.IndexChanger.delete(IndexChanger.java:544)
   at 
 org.apache.derby.impl.sql.execute.IndexSetChanger.delete(IndexSetChanger.java:250)
   at 
 org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(RowChangerImpl.java:476)
   at 
 org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(DeleteResultSet.java:405)
   at 
 org.apache.derby.impl.sql.execute.DeleteResultSet.open(DeleteResultSet.java:137)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:372)
   at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1234)
   - locked 0xfab36948 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at 
 org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:624)
   -

[jira] Updated: (DERBY-3326) Introduce a caching logical connection and logical prepared statement in the client driver


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

Kristian Waagan updated DERBY-3326:
---

Derby Info:   (was: [Patch Available])

Committed 'derby-3326-7a-prepare_column_indexes_names_fix.diff' to trunk with 
revision 631569.

 Introduce a caching logical connection and logical prepared statement in the 
 client driver
 --

 Key: DERBY-3326
 URL: https://issues.apache.org/jira/browse/DERBY-3326
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
 Fix For: 10.4.0.0

 Attachments: derby-3326-1a_cpds_testing_preparation.diff, 
 derby-3326-1a_cpds_testing_preparation.stat, 
 derby-3326-1b_cpds_testing_preparation.diff, 
 derby-3326-2a-method_rename.diff, derby-3326-3a-new_classes.diff, 
 derby-3326-3a-new_classes.stat, derby-3326-3b-new_classes.diff, 
 derby-3326-3b-new_classes.stat, derby-3326-3c-new_classes.diff, 
 derby-3326-4a-cpdsc_shutEngine.diff, 
 derby-3326-5a-enable_logicalstmtentity_pptest.diff, 
 derby-3326-6a-npe_fix_synch_CLC.diff, derby-3326-6b-npe_fix_synch_CLC.diff, 
 derby-3326-7a-prepare_column_indexes_names_fix.diff


 A logical connection with statement caching capabilities is required to 
 support JDBC prepared statement pooling. Further, a logical prepared 
 statement object is also needed.
 The logical prepared statements will be generated by the logical connection's 
 'prepareStatement'-method.

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

[jira] Updated: (DERBY-3473) write test cases to test locking during tree operation


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

Anurag Shekhar updated DERBY-3473:
--

Attachment: derby-3473.diff

This patch has test case to test insert while the record is deleted  from a 
different transaction. If the other transaction commits insert should pass 
otherwise should result in intergrityConstraintviolation exception. 

This patch is not meant for commit but to get the others views and ideas about 
what other test cases I should be adding to it. 

 write test cases to test locking during tree operation
 --

 Key: DERBY-3473
 URL: https://issues.apache.org/jira/browse/DERBY-3473
 Project: Derby
  Issue Type: Sub-task
Affects Versions: 10.4.0.0
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Priority: Minor
 Attachments: derby-3473.diff




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

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack (and SQL session context to hold it)

2008-02-27 Thread Dag H. Wanvik (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572894#action_12572894
]

Dag H. Wanvik commented on DERBY-3327:
--

Ran some performance tests to see if the new code for getting current schema
had any substantial impact on performance, but it seems not (a loop executing
CURRENT SCHEMA inside a stored procedure saw a 3-5% performance hit, which is
not unreasonable since access is no longer just a simple field access in lcc
but
incurs 3 extra method calls).

If there are no further comments, I will commit this patch in a few days.

SQL roles: Implement authorization stack (and SQL session context to hold it)
-

Key: DERBY-3327
URL: https://issues.apache.org/jira/browse/DERBY-3327
Project: Derby
Issue Type: New Feature
Components: Security, SQL
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
Fix For: 10.4.0.0

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat,
DERBY-3327-4-full-b.diff, DERBY-3327-4-full-b.stat, DERBY-3327-4-full-c.diff,
DERBY-3327-4-full-c.stat, DERBY-3327-4-full.diff, DERBY-3327-4-full.stat

The current LanguageConnectionContext keeps the user authorization identifier
for an SQL session.
The lcc is shared context also for nested connections (opened from stored
procedures).
So far, for roles, the current role has been stored in the lcc also. However,
SQL requires that
authorization identifers be pushed on a authorization stack when calling a
stored procedure, cf.
SQL 2003, vol 2, section 4.34.1.1 and 4.27.3.
This allows a caller to keep its current role after a call even if changed by
the stored procedure.
This issue will implement the current role name part (cell) of the
authorization stack.

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

[jira] Updated: (DERBY-3458) dblook fails on TERRITORY_BASED databases

2008-02-27 Thread Stephan van Loendersloot (JIRA)


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

Stephan van Loendersloot updated DERBY-3458:


Derby Info:   (was: [Patch Available])

Marking patch as unavailable. The test functionality for 'derbyall' doesn't 
complete. It looks like I need to rename the output of dblook after each test 
to prevent successive tests from failing. Will be back with a new patch when 
'derbyall' completes successfully.


 dblook fails on TERRITORY_BASED databases
 -

 Key: DERBY-3458
 URL: https://issues.apache.org/jira/browse/DERBY-3458
 Project: Derby
  Issue Type: Bug
  Components: Tools
Affects Versions: 10.3.2.1
Reporter: Stephan van Loendersloot
Assignee: Stephan van Loendersloot
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: DERBY-3458_patch_1.stat, DERBY-3458_patch_1.txt, 
 DERBY-3458_patch_2.stat, DERBY-3458_patch_2.txt, DERBY-3458_patch_3.stat, 
 DERBY-3458_patch_3.txt, DERBY-3458_patch_3_function_tests.txt


 I've created small patches for myself by replacing all related queries in the 
 'tools' section with CASTs to CHARs and VARCHARs and would like to contribute 
 these to the community in case anyone else can confirm this is a bug.
 A small test case to reproduce the problem is provided below, the version of 
 Derby that provides the stacktrace is 10.3.2.1.
 Regards,
 Stephan van Loendersloot.
 Reproduction steps:
 -- 1: create_territory_db.sql  --
 CONNECT 
 'jdbc:derby://localhost/dutch;user=dutch;password=dutch;create=true;territory=nl_NL;collation=TERRITORY_BASED';
 AUTOCOMMIT OFF;
 CREATE TABLE AIRLINES
  (
 AIRLINE CHAR(2) NOT NULL ,
 AIRLINE_FULL VARCHAR(24),
 BASIC_RATE DOUBLE PRECISION,
 DISTANCE_DISCOUNT DOUBLE PRECISION,
 BUSINESS_LEVEL_FACTOR DOUBLE PRECISION,
 FIRSTCLASS_LEVEL_FACTOR DOUBLE PRECISION,
 ECONOMY_SEATS INTEGER,
 BUSINESS_SEATS INTEGER,
 FIRSTCLASS_SEATS INTEGER
  );
 COMMIT;
 DISCONNECT;
 EXIT;
 -- 2: use dbloook --
 dblook -d jdbc:derby://localhost/dutch;user=dutch;password=dutch -o 
 dutch.sql
 -- 3: stacktrace --
 java.sql.SQLSyntaxErrorException: Comparisons between 'CHAR (UCS_BASIC)' and 
 'CHAR (TERRITORY_BASED)' are not supported. Types must be comparable. String 
 types must also have matching collation. If collation does not match, a 
 possible solution is to cast operands to force them to the default collation 
 (e.g. select tablename from sys.systables where CAST(tablename as 
 VARCHAR(128)) = 'T1')
   at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
 Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
   at org.apache.derby.client.am.Statement.executeQuery(Unknown Source)
   at org.apache.derby.tools.dblook.prepForDump(Unknown Source)
   at org.apache.derby.tools.dblook.go(Unknown Source)
   at org.apache.derby.tools.dblook.init(Unknown Source)
   at org.apache.derby.tools.dblook.main(Unknown Source)
 Caused by: org.apache.derby.client.am.SqlException: Comparisons between 'CHAR 
 (UCS_BASIC)' and 'CHAR (TERRITORY_BASED)' are not supported. Types must be 
 comparable. String types must also have matching collation. If collation does 
 not match, a possible solution is to cast operands to force them to the 
 default collation (e.g. select tablename from sys.systables where 
 CAST(tablename as VARCHAR(128)) = 'T1')
   at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
   at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown
  Source)
   at 
 org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown 
 Source)
   at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown 
 Source)
   at org.apache.derby.client.am.Statement.flowExecute(Unknown Source)
   at org.apache.derby.client.am.Statement.executeQueryX(Unknown Source)
   ... 5 more
 -- **-- DEBUG: Comparisons between 'CHAR (UCS_BASIC)' and 'CHAR 
 (TERRITORY_BASED)' are not supported. Types must be comparable. String types 
 must also have matching collation. If collation does not match, a possible 
 solution is to cast operands to force them to the default collation (e.g. 
 select tablename from sys.systables where CAST(tablename as VARCHAR(128)) = 
 'T1') 

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

[jira] Updated: (DERBY-3472) Replication: Thread deadlock when deleting many records.


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

Jørgen Løland updated DERBY-3472:
-

Attachment: derby-3472-1a.diff
derby-3472-1a.stat

The deadlock appears because mf.workToDo is called while holding the listLatch 
in ReplicationLogBuffer. Patch v1a moves the mf.workToDo call outside the 
synchronized block. 

Running tests.

 Replication: Thread deadlock when deleting many records.
 

 Key: DERBY-3472
 URL: https://issues.apache.org/jira/browse/DERBY-3472
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Derby trunk revision 631534 + DERBY 3205 patch 
 failover-slave-2a.
Reporter: Øystein Grøvlen
Assignee: Jørgen Løland
 Attachments: derby-3472-1a.diff, derby-3472-1a.stat


 When I tried to delete ca 28 records from a table while replication was 
 running, the statement never completed.
 VisualVM reports a deadlock:
 Found one Java-level deadlock:
 =
 Thread-2:
   waiting to lock monitor 0x08164e4c (object 0xfa9db5f8, a java.lang.Object),
   which is held by main
 main:
   waiting to lock monitor 0x08164d20 (object 0xfa9db608, a 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper),
   which is held by Thread-2
 Java stack information for the threads listed above:
 ===
 Thread-2:
   at 
 org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.next(ReplicationLogBuffer.java:182)
   - waiting to lock 0xfa9db5f8 (a java.lang.Object)
   at 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.shipALogChunk(AsynchronousLogShipper.java:218)
   - locked 0xfa9db608 (a 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper)
   at 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.run(AsynchronousLogShipper.java:169)
 main:
   at 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper.workToDo(AsynchronousLogShipper.java:336)
   - waiting to lock 0xfa9db608 (a 
 org.apache.derby.impl.services.replication.master.AsynchronousLogShipper)
   at 
 org.apache.derby.impl.services.replication.master.MasterController.workToDo(MasterController.java:472)
   at 
 org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.switchDirtyBuffer(ReplicationLogBuffer.java:322)
   at 
 org.apache.derby.impl.services.replication.buffer.ReplicationLogBuffer.appendLog(ReplicationLogBuffer.java:148)
   - locked 0xfa9db5f8 (a java.lang.Object)
   at 
 org.apache.derby.impl.services.replication.master.MasterController.appendLog(MasterController.java:328)
   at 
 org.apache.derby.impl.store.raw.log.LogAccessFile.writeToLog(LogAccessFile.java:787)
   - locked 0xbb041788 (a org.apache.derby.impl.io.DirRandomAccessFile4)
   at 
 org.apache.derby.impl.store.raw.log.LogAccessFile.flushDirtyBuffers(LogAccessFile.java:534)
   at 
 org.apache.derby.impl.store.raw.log.LogAccessFile.switchLogBuffer(LogAccessFile.java:611)
   - locked 0xbb041618 (a 
 org.apache.derby.impl.store.raw.log.LogAccessFile)
   at 
 org.apache.derby.impl.store.raw.log.LogAccessFile.reserveSpaceForChecksum(LogAccessFile.java:855)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3737)
   - locked 0xbb041528 (a org.apache.derby.impl.store.raw.log.LogToFile)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:370)
   - locked 0xfab06ec8 (a org.apache.derby.impl.store.raw.log.FileLogger)
   at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1193)
   at 
 org.apache.derby.impl.store.raw.data.LoggableActions.doAction(LoggableActions.java:221)
   at 
 org.apache.derby.impl.store.raw.data.LoggableActions.actionDelete(LoggableActions.java:64)
   at 
 org.apache.derby.impl.store.raw.data.BasePage.deleteAtSlot(BasePage.java:1149)
   at 
 org.apache.derby.impl.store.access.btree.BTreeScan.delete(BTreeScan.java:1386)
   at 
 org.apache.derby.impl.sql.execute.IndexChanger.doDelete(IndexChanger.java:369)
   at 
 org.apache.derby.impl.sql.execute.IndexChanger.delete(IndexChanger.java:544)
   at 
 org.apache.derby.impl.sql.execute.IndexSetChanger.delete(IndexSetChanger.java:250)
   at 
 org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(RowChangerImpl.java:476)
   at 
 org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(DeleteResultSet.java:405)
   at 
 org.apache.derby.impl.sql.execute.DeleteResultSet.open(DeleteResultSet.java:137)
   at

[jira] Created: (DERBY-3475) Replication: Slave reports ERROR XSLA7: Cannot redo operation null in the log.

Replication:  Slave reports ERROR XSLA7: Cannot redo operation null in the log.
---

 Key: DERBY-3475
 URL: https://issues.apache.org/jira/browse/DERBY-3475
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Derby trunk revision 631534 + DERBY 3205 patch 
failover-slave-2a.
Reporter: Øystein Grøvlen


Master:
ij connect 
'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost';
ij(CONNECTION1) delete from t where i  8192;
253952 rows inserted/updated/deleted
ij(CONNECTION1) connect 
'jdbc:derby:masterDB;user=oystein;password=pass;failover=true';
ERROR XJ001: Java exception: ': java.lang.NullPointerException'.

Slave reports in the log:


  BEGIN SHUTDOWN ERROR STACK -

ERROR XSLA7: Cannot redo operation null in the log.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:296)
at 
org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1525)
at 
org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at 
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
at 
org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
at 
org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at 
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
at 
org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
at 
org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:793)
at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205)
at 
org.apache.derby.impl.db.SlaveDatabase.bootBasicDatabase(SlaveDatabase.java:425)
at 
org.apache.derby.impl.db.SlaveDatabase.access$000(SlaveDatabase.java:70)
at 
org.apache.derby.impl.db.SlaveDatabase$SlaveDatabaseBootThread.run(SlaveDatabase.java:312)
at java.lang.Thread.run(Thread.java:619)
Caused by: ERROR XSLAO: Recovery failed unexpected problem log record is Not 
first but transaction is not in transaction table : 58625.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
at 
org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1289)
... 17 more
= begin nested exception, level (1) ===
ERROR XSLAO: Recovery failed unexpected problem log record is Not first but 
transaction is not in transaction table : 58625.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
at 
org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1289)
at 
org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at 
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
at 
org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
at 
org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at 
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
at 
org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
at 
org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:793)
at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205)
at 
org.apache.derby.impl.db.SlaveDatabase.bootBasicDatabase(SlaveDatabase.java:425)
at 
org.apache.derby.impl.db.SlaveDatabase.access$000(SlaveDatabase.java:70)
at 
org.apache.derby.impl.db.SlaveDatabase$SlaveDatabaseBootThread.run(SlaveDatabase.java:312)
at java.lang.Thread.run(Thread.java:619)
= end nested exception, level (1) ===


  END SHUTDOWN ERROR

[jira] Updated: (DERBY-3457) Closing a logical connection must close all associated logical statements

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

Kristian Waagan updated DERBY-3457:
---

Attachment: derby-3457-2a-stmt_registration.diff

'derby-3457-2a-stmt_registration.diff' is a partial patch adding registration
of the logical statements when they are created. I will add the remaining logic
as patch 1c (or higher).
I split patch 1b into two parts, because I need review of the most critical
part of the change, and I think the changes done in 2a is pretty straight
forward and not as important as 1c will be.

Committed 2a to trunk with revision 631577.
Patch 1c will follow shortly.

Closing a logical connection must close all associated logical statements
-

Key: DERBY-3457
URL: https://issues.apache.org/jira/browse/DERBY-3457
Project: Derby
Issue Type: Task
Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Environment: Client-server with statement pooling enabled in the
client driver.
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Fix For: 10.4.0.0

Attachments: derby-3457-1a-stmt_closing.diff,
derby-3457-1a-stmt_closing.stat, derby-3457-1b-stmt_closing.diff,
derby-3457-2a-stmt_registration.diff

When a logical connection is closed, all open logical statements created by
this connection must be closed.
The closing is important per the general principle of cleaning up resources,
but especially so in the case of statement pooling, as not closing the
logical statement can cause side effects on another logical connection
(sharing the same physical connection).

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

[jira] Commented: (DERBY-3441) Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool


[ 
https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572904#action_12572904
 ] 

Kristian Waagan commented on DERBY-3441:


I have run suties.All and derbyall without failures with patch 2a, Sun JDK 
1.6.0 on Solaris 10.

 Determine and implement a proper procedure for resetting a prepared statement 
 for reuse in a statement pool
 ---

 Key: DERBY-3441
 URL: https://issues.apache.org/jira/browse/DERBY-3441
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
 Fix For: 10.4.0.0

 Attachments: derby-3441-1a-statement_reset.diff, 
 derby-3441-2a-minor_am_refactoring.diff


 Initial investigations indicate there are no existing suitable methods to 
 properly reset a prepared (or callable) statement for reuse with a statement 
 pool.
 A full reset is too heavy weight and defeats the purpose of statement 
 pooling, but a proper procedure should be achievable by reusing existing 
 pieces of code.
 Correctness is of course the most important thing.

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

[jira] Commented: (DERBY-3475) Replication: Slave reports ERROR XSLA7: Cannot redo operation null in the log.


[ 
https://issues.apache.org/jira/browse/DERBY-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572898#action_12572898
 ] 

Øystein Grøvlen commented on DERBY-3475:


If I try to do recovery on the slave database, I get the same error again:

  BEGIN SHUTDOWN ERROR STACK -

ERROR XSLA7: Cannot redo operation null in the log.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:296)
at 
org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1525)
at 
org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at 
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
at 
org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
at 
org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at 
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
at 
org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
at 
org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:793)
at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at 
org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1836)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1702)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1582)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:1001)
at 
org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:542)
at 
org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2369)
at 
org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:336)
at 
org.apache.derby.impl.jdbc.EmbedConnection30.init(EmbedConnection30.java:73)
at 
org.apache.derby.impl.jdbc.EmbedConnection40.init(EmbedConnection40.java:54)
at 
org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68)
at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:226)
at 
org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:1238)
at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:1088)
at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:916)
at 
org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:328)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)
at org.apache.derby.tools.ij.main(ij.java:59)
at org.apache.derby.iapi.tools.run.main(run.java:51)
Caused by: ERROR XSLAO: Recovery failed unexpected problem log record is Not 
first but transaction is not in transaction table : 58625.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
at 
org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1289)
... 39 more
= begin nested exception, level (1) ===
ERROR XSLAO: Recovery failed unexpected problem log record is Not first but 
transaction is not in transaction table : 58625.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
at 
org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1289)
at 
org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
at

[jira] Issue Comment Edited: (DERBY-3457) Closing a logical connection must close all associated logical statements

[
https://issues.apache.org/jira/browse/DERBY-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572906#action_12572906
]

kristwaa edited comment on DERBY-3457 at 2/27/08 5:41 AM:
-

'derby-3457-1c-stmt_closing.diff' adds the closing logic for logical statements.
The basic approach taken is that each new logical statement is registered by
the StatementCacheInteractor.
When a logical statement is explicitly closed, it removes itself from the list
of open statements.
When the caching logical connection is closed, it iterates through the list of
open statements and closes them.

Possible issues:
a) What should happen if closing a statement throws exception?
Currently, the close procedure is aborted, and I'm not quite sure what
state the connection is left in.
The close can fail on statement reset, or on physical statement close. Not
sure which errors can occur, except for network problems.

There is also a possible issue with calling super.close in
CachingLogicalConnection. That method cannot close open statements when called
from a CLC, but it should do it when called on a LogicalConnection. This
suggests a bug somewhere, and I have to look into this to determine if the
existing LogicalConnection has a bug, or if it is the new code I have added.

Patch 1c ready for review.

was (Author: kristwaa):
'derby-3457-1c-stmt_closing.diff' adds the closing logic for logical
statements.
The basic approach taken is that each new logical statement is registered by
the StatementCacheInteractor.
When a logical statement is explicitly closed, it removes itself from the list
of open statements.
When the caching logical connection is closed, it iterates through the list of
open statements and closes them.

Patch 1d ready for review.

Closing a logical connection must close all associated logical statements
-

Attachments: derby-3457-1a-stmt_closing.diff,
derby-3457-1a-stmt_closing.stat, derby-3457-1b-stmt_closing.diff,
derby-3457-1c-stmt_closing.diff, derby-3457-2a-stmt_registration.diff

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

[jira] Updated: (DERBY-3457) Closing a logical connection must close all associated logical statements

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

Kristian Waagan updated DERBY-3457:
---

Attachment: derby-3457-1c-stmt_closing.diff

Patch 1d ready for review.

Closing a logical connection must close all associated logical statements
-

Attachments: derby-3457-1a-stmt_closing.diff,
derby-3457-1a-stmt_closing.stat, derby-3457-1b-stmt_closing.diff,
derby-3457-1c-stmt_closing.diff, derby-3457-2a-stmt_registration.diff

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

[jira] Commented: (DERBY-3445) Make it easier to use the EMMA tool to measure the code coverage of the Derby testing

[
https://issues.apache.org/jira/browse/DERBY-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572905#action_12572905
]

Vemund Østgaard commented on DERBY-3445:

I haven't found any problems with this change and ant 1.6. My experience with
ant 1.6 is that to get things to work you need to use one of the workarounds
described here: http://ant.apache.org/faq.html#delegating-classloader-1.6:

1. put all external libraries you need in CLASSPATH as well this is not
what you want, otherwise you wouldn't have found this FAQ entry.
2. put all external libraries you need in ANT_HOME/lib or .ant/lib. This
probably still isn't what you want, but you might reconsider the .ant/lib
option.
3. Always start Ant with the -lib command line switch and point to your
external libraries (or the directories holding them).
4. remove the class that loads the external library from the coreloader.

So, basically my change has no effect with ant 1.6, it neither helps nor harms
as far as I can understand. I am able to test with ant 1.6 if I for instance
use the -lib option with ant.

If you are using ant 1.7 with my patch you just need to have junit.jar under
your tools/java/ directory where the ant properties expect it to be. In my work
environment that is a better solution than the various workarounds for ant 1.6.

Make it easier to use the EMMA tool to measure the code coverage of the Derby
testing
-

Key: DERBY-3445
URL: https://issues.apache.org/jira/browse/DERBY-3445
Project: Derby
Issue Type: Improvement
Components: Build tools
Reporter: Vemund Østgaard
Assignee: Vemund Østgaard
Attachments: 3445-general-diff, 3445-general-diffv2,
3445-testspecific-diff, 3445-testspecific-diffv2

It is a bit tricky to use EMMA to measure code coverage for the derby testing.
Modifications must be made to the source both to avoid problems with the
SecurityManager and individual tests. It would be good if these modifcations
could be done once and for all so that it was easier for anyone to run the
tests with EMMA.
It would also be good to have ant tasks that would make it even easier to run
the tests with EMMA.

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

[jira] Assigned: (DERBY-3475) Replication: Slave reports ERROR XSLA7: Cannot redo operation null in the log.


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

Jørgen Løland reassigned DERBY-3475:


Assignee: Jørgen Løland

 Replication:  Slave reports ERROR XSLA7: Cannot redo operation null in the 
 log.
 ---

 Key: DERBY-3475
 URL: https://issues.apache.org/jira/browse/DERBY-3475
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Derby trunk revision 631534 + DERBY 3205 patch 
 failover-slave-2a.
Reporter: Øystein Grøvlen
Assignee: Jørgen Løland
 Attachments: slaveDB.zip


 Master:
 ij connect 
 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost';
 ij(CONNECTION1) delete from t where i  8192;
 253952 rows inserted/updated/deleted
 ij(CONNECTION1) connect 
 'jdbc:derby:masterDB;user=oystein;password=pass;failover=true';
 ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
 Slave reports in the log:
   BEGIN SHUTDOWN ERROR STACK -
 ERROR XSLA7: Cannot redo operation null in the log.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:296)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1525)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
   at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
   at 
 org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
   at 
 org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:793)
   at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205)
   at 
 org.apache.derby.impl.db.SlaveDatabase.bootBasicDatabase(SlaveDatabase.java:425)
   at 
 org.apache.derby.impl.db.SlaveDatabase.access$000(SlaveDatabase.java:70)
   at 
 org.apache.derby.impl.db.SlaveDatabase$SlaveDatabaseBootThread.run(SlaveDatabase.java:312)
   at java.lang.Thread.run(Thread.java:619)
 Caused by: ERROR XSLAO: Recovery failed unexpected problem log record is Not 
 first but transaction is not in transaction table : 58625.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1289)
   ... 17 more
 = begin nested exception, level (1) ===
 ERROR XSLAO: Recovery failed unexpected problem log record is Not first but 
 transaction is not in transaction table : 58625.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1289)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
   at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
   at 
 org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
   at 
 org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:793)
   at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205)
   at 
 org.apache.derby.impl.db.SlaveDatabase.bootBasicDatabase(SlaveDatabase.java:425)
   at

[jira] Updated: (DERBY-3475) Replication: Slave reports ERROR XSLA7: Cannot redo operation null in the log.


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

Øystein Grøvlen updated DERBY-3475:
---

Attachment: slaveDB.zip

slaveDB.zip contains the slave database.
Doing recovery on this DB should provoke the error.



 Replication:  Slave reports ERROR XSLA7: Cannot redo operation null in the 
 log.
 ---

 Key: DERBY-3475
 URL: https://issues.apache.org/jira/browse/DERBY-3475
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Derby trunk revision 631534 + DERBY 3205 patch 
 failover-slave-2a.
Reporter: Øystein Grøvlen
 Attachments: slaveDB.zip


 Master:
 ij connect 
 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost';
 ij(CONNECTION1) delete from t where i  8192;
 253952 rows inserted/updated/deleted
 ij(CONNECTION1) connect 
 'jdbc:derby:masterDB;user=oystein;password=pass;failover=true';
 ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
 Slave reports in the log:
   BEGIN SHUTDOWN ERROR STACK -
 ERROR XSLA7: Cannot redo operation null in the log.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:296)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1525)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
   at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
   at 
 org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
   at 
 org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:793)
   at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205)
   at 
 org.apache.derby.impl.db.SlaveDatabase.bootBasicDatabase(SlaveDatabase.java:425)
   at 
 org.apache.derby.impl.db.SlaveDatabase.access$000(SlaveDatabase.java:70)
   at 
 org.apache.derby.impl.db.SlaveDatabase$SlaveDatabaseBootThread.run(SlaveDatabase.java:312)
   at java.lang.Thread.run(Thread.java:619)
 Caused by: ERROR XSLAO: Recovery failed unexpected problem log record is Not 
 first but transaction is not in transaction table : 58625.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1289)
   ... 17 more
 = begin nested exception, level (1) ===
 ERROR XSLAO: Recovery failed unexpected problem log record is Not first but 
 transaction is not in transaction table : 58625.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1289)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
   at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
   at 
 org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419)
   at 
 org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:793)
   at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205)
   at

[jira] Commented: (DERBY-3192) Cache session data in the client driver

[
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572909#action_12572909
]

Dyre Tjeldvoll commented on DERBY-3192:
---

Committed revision 631593

Cache session data in the client driver
---

Key: DERBY-3192
URL: https://issues.apache.org/jira/browse/DERBY-3192
Project: Derby
Issue Type: Improvement
Components: JDBC, Network Client, Network Server, Performance, SQL
Affects Versions: 10.3.1.4
Reporter: Dyre Tjeldvoll
Assignee: Dyre Tjeldvoll
Attachments: derby-3192-mark2.v1.diff, derby-3192-mark2.v2.diff,
derby-3192-mark2.v3.diff, derby-3192-mark2.v4.diff, derby-3192-mark2.v5.diff,
derby-3192-mark2.v6.diff, derby-3192-mark2.v7.diff, derby-3192-mark2.v8.diff,
derby-3192-test.fup1.diff, derby-3192-test.fup2.diff,
derby-3192-test.v1.diff, derby-3192-test.v1.stat, derby-3192.prelim1.diff

The reason for doing this is to avoid a rather
substantial performance hit observed when the client driver is used
together with an appserver that uses connection pooling. There are two
problems:
1) The connection pool will compare the isolation level it has
stored for the connection with the value returned from
Connection.getTransactionIsolation() each and every time someone
requests a new connection from the pool.
2) The users of the connection pool (ab)use it to avoid having to keep
track of their current connection. So each time a query needs to be
executed a call to the connection pool's getConnection() method is
made. Getting a connection from the connection pool like this also
means that a new PreparedStatement must be prepared each time.
The net result is that each query results in the following sequence:
getConnection()
getTransactionIsolation() -- roundtrip + lookup in server's statement cache
prepareStatment() -- roundtrip + lookup in server's statement cache
executeQuery()-- roundtrip
Arguably this is a user error but when suggesting this I'm kindly
informed that this works just fine with other datbases (such as
PostgreSQL and ORACLE).
The reason why it works is that these databases do statement caching
in the driver. I've tried to implement a very (too) simple statement
cache in Derby's client driver and to re-enable caching of the
isolation level (see
https://issues.apache.org/jira/browse/DERBY-1148). With these changes
I observe a marked performance improvement when running with appserver
load.
A proper statment cache cannot be implemented without knowing what the
current schema is. If the current schema has changed since the
statement was prepared, it is no longer valid and must be evicted from
the cache.
The problem with caching both the isolation level and the current schema in
the driver is that both can change on the server without the client
detecting it (through SQL and XA and possibly stored procedures).
I think this problem can be overcome if we piggy-back the information we
would
like to cache on messages going back to the client. This can be done by
utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume
3,
page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD
in the reply,
I think it would be possible to cache additional session information when
this becomes relevant. It
would also be possible to use EXCSQLSET to batch session state changes
going from the client to the server.

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

[jira] Updated: (DERBY-3435) Add an MBean for monitoring and managing the Network Server

2008-02-27 Thread Bernt M. Johnsen (JIRA)

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

Bernt M. Johnsen updated DERBY-3435:

Attachment: derby-3435-live-data-v0.stat
derby-3435-live-data-v0.diff

Uploaded a patch that adds some live data to the network server MBean
- Active sessions
- Waiting sessions
- No of connection threads
- No of accepted connections
- Bytes sent
- Bytes received

Add an MBean for monitoring and managing the Network Server
---

Key: DERBY-3435
URL: https://issues.apache.org/jira/browse/DERBY-3435
Project: Derby
Issue Type: Sub-task
Components: JMX
Reporter: John H. Embretsen
Assignee: John H. Embretsen
Fix For: 10.4.0.0

Attachments: d3435_v01.diff, d3435_v01.stat,
derby-3435-live-data-v0.diff, derby-3435-live-data-v0.stat

Most functionality of and information about a running instance of the Network
Server is currently only available from the host running the Network Server,
using the NetworkServerControl API.
With a JMX Management and Monitoring service in place utilizing JMX
(DERBY-1387), it is possible to expose some of the Network Server
functionality and information through an MBean that is specific to the
Network Server, to both local and remote users (JMX clients), subject to
security restrictions. Access to Derby libraries on the client side is not
even a requirement, potentially making a server administrator's job a lot
easier.

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

[jira] Commented: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes

2008-02-27 Thread Knut Anders Hatlen (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572924#action_12572924
 ] 

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

I've gone through the comments and questions. Please find my
responses below. Regarding the correctness error (4e), I think the
code is actually correct, but it could have been clearer.

The new buffer manager isn't enabled in the build yet. Should the
issues mentioned by Øystein be resolved first, or would it be OK to
enable it first and do the reorganization and improvements later?

Responses to Øystein's questions/comments:

1. ConcurrentCache

a) Difference between evictEntry() and removeEntry().

I think you are right that the only significant difference is that
removeEntry() calls free() whereas evictEntry() doesn't. Calling
free() from evictEntry() wouldn't be correct in the current code,
though. free() is called to notify the replacement policy that the
Cacheable contained in the entry can be reused. When evictEntry() is
called, we're either in the process of reusing the Cacheable (in which
case we don't want to first mark it as reusable so that others can
grab it, and then try to reobtain it and possibly reuse it), or we're
shrinking the cache (in which case making it reusable would mean that
the cache doesn't shrink).

I'll see if I can find a clever way to merge the two methods, or at
least improve the comments and perhaps the names of the methods.

b) Organization of find and create methods.

I guess it is possible to split them into two or three basic methods
and build the public methods on top of them. However, I'm not sure
it's a good idea to remove the create flag. findOrCreateObject() is a
fairly large method, and the check of the create flag is a very small
part of it. If the create flag were removed, it would mean that we
have to duplicate a most of the logic in that method. But if we split
the logic into more basic methods, it will hopefully be easier to
understand how the create flag affects each of the basic methods.

c) findOrCreateObject(): create vs createParameter

create can be true even if createParameter is null, so I don't think
create can be skipped. The distinction between setIdentity() and
createIdentity() comes from the Cacheable interface and can't be
changed without modifying the existing buffer manager and the store as
well.

d) findCached()/release(): get() vs getEntry()

You're right, it is not harmful to call getEntry() in terms of
correctness, but it's slightly more expensive. I will update the
comments to make this clearer.

2. CacheEntry

a) Misleading name: lockWhenIdentityIsSet()

Your suggestion lockAndBlockUntilIdentityIsSet() does match more
closely the calls in the method (lock() + await()), but since await()
will release the lock until it wakes up, I think the original name
describes better how the locking and blocking is perceived from
outside the method. Perhaps waitUntilIdentityIsSetAndLock() is a
better name? Of course, better comments in the method would also help.

3. ReplacementPolicy

a) Return value from insertEntry() isn't used.

The return value isn't needed since the replacement policy will link
the CacheEntry and the Callback internally by calling
CacheEntry.setCallback(). Will change the method so that it's void.

4. ClockPolicy

a) Why not synchronize inside grow()?

One of the callers needs the synchronization for more than just the
call to grow() and therefore needs the synchronized block anyway, so I
felt it was more consistent if all (both) callers used an explicit
synchronization block. (It also avoided double synchronization for
that caller.) The other methods you mention are supposed to be atomic,
and are not intended to be called from within a larger block
synchronized on the same object.

b) Handling of small cache sizes in rotateClock().

I agree that this is a bit strange. The logic is copied from
Clock.rotateClock(), by the way. I believe you are correct that it's
not relevant for the (default) cache sizes currently used (none is
smaller than 32). Perhaps it would be better to simplify it and just
say itemsToCheck = Math.max(20, ...) or something (the number 20 is
arbitrary).

c) Add more comments about why cleaned entries are not reused.

Will update the comments with more details from the JIRA discussion.

d) Incomplete @return tag for shrinkMe().

Thanks, fixed in revision 631225.

e) Off-by-one error in shrinkMe().

I don't think there is an off-by-one error, since we use the old value
of pos, not the one that has been increased by one. I guess it's a bit
confusing to use the postfix increment operator and store away the old
value on the same line in the code. Perhaps it would be clearer if the
code were reordered from

index = pos++;
h = clock.get(index);

to

h = clock.get(pos);
index = pos;

Re: 10.4 Feature Freeze

2008-02-27 Thread Rick Hillegas


Daniel John Debrunner wrote:

[EMAIL PROTECTED] wrote:

John Embretsen [EMAIL PROTECTED] writes:


[EMAIL PROTECTED] wrote:

... is fast approaching (2008-02-29)

Is this still a reasonable date, or should we consider delaying it?


Here is the current status (based on what I know):
JMX  On track
JMX is on track per se, as it has not been defined what exactly will 
be part of
10.4. However, this is still work in progress, but I guess it is up 
to you as

release manager to decide what to let into the release or not.


It is, but some JMX stuff has already been committed, hasn't it. And
since what Derby offers through JMX isn't regulated by a standard, I
would think that you have quite a bit of leeway in terms of defining
when the feature is complete... :)


I'm trying to add Java security manager checks (DERBY-3462) to the JMX 
MBeans so that security is not compromised by the addition of JMX. 
While I'm not blocked by DERBY-2109, if I proceed ahead of DERBY-2019 
committing code JMX related permission code then any DERBY-2109 patch 
will have to re-worked again. However since there doesn't seem to be 
any activity on DERBY-2109 I may just go ahead anyway.


Dan.
Please do not do this, at least not in a way which will make it 
necessary to rework and retest DERBY-2109. Martin is actively working on 
this feature and deserves our patience and respect. Each rework/retest 
cycle is turning out to be very expensive.


-Rick

[jira] Updated: (DERBY-3441) Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool

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

Kristian Waagan updated DERBY-3441:
---

Attachment: derby-3441-1b-statement_reset.diff

'derby-3441-1b-statement_reset.diff' is another try at a proper reset procedure.
The following has been changed:
a) Added JavaDoc to Statement.resetForReuse
b) Extracted user controllable attributes from the init method, and put them
into a separate method.
These attributes must be reset when the statement is put into the cache.
Examples are query timeout, fetch direction hint and max rows to fetch.
c) The allowAutoCommit argument for willTickleServer(), is now set to
connection_.autoCommit
Does anyone have any useful info on the willTickleServer method?
d) Calling batch_.clear() (ArrayList) instead of clearBatch(), to avoid
catching/throwing SQLException.
See related comment for patch 2a above.
e) Removed the outer try-catch clause, and the method now throws SqlException.

Dan, I hope your comments are addressed.
Having slugged through the code, did anything come across as strange?
I.e. why is X reset, but not Y?

Patch ready for review.
I hope to commit later today, even if I don't have full confidence in the
patch. It is a lot better than the current solution anyway, and I'll work on
improving it. When the patch for this issue is committed, I will enable the
statement pooling code by committing DERBY-3329.
The other know new defect is DERBY-3457, which has a patch awaiting review as
well.

Determine and implement a proper procedure for resetting a prepared statement
for reuse in a statement pool
---

Attachments: derby-3441-1a-statement_reset.diff,
derby-3441-1b-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff

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

Re: 10.4 Feature Freeze

2008-02-27 Thread Knut Anders Hatlen

[EMAIL PROTECTED] writes:

 ... is fast approaching (2008-02-29)

 Is this still a reasonable date, or should we consider delaying it?


 Here is the current status (based on what I know):
[...]
 Buffer manager   On track

Hi Dyre,

The code for the buffer manager has been in the repository for quite
some time now, but it has not yet been enabled in
modules.properties. Øystein has reviewed the code and suggested some
improvements. I'll probably not have the time to make all the changes
Øystein suggested before the feature freeze date, but since the
improvements are mainly reorganizing some methods and improving the
comments, I think we could just as well enable it now before the
improvements have been made. I have just asked about it on JIRA, and
I'll wait until someone says go ahead before I enable it.

-- 
Knut Anders

[jira] Commented: (DERBY-3460) SQL roles: patch to mask off roles on 10.4 release branch


[ 
https://issues.apache.org/jira/browse/DERBY-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572937#action_12572937
 ] 

Dyre Tjeldvoll commented on DERBY-3460:
---

I had a quick look at the patch, and I think the approach you have chosen looks 
reasonable. +1

 SQL roles: patch to mask off roles on 10.4 release branch
 -

 Key: DERBY-3460
 URL: https://issues.apache.org/jira/browse/DERBY-3460
 Project: Derby
  Issue Type: Task
  Components: Security, SQL
Affects Versions: 10.4.0.0
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
 Fix For: 10.4.0.0

 Attachments: DERBY-3460a.diff, DERBY-3460a.stat


 Since the roles feature is not complete, provide a patch for masking the 
 feature in the 10.4 release branch.

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

[jira] Updated: (DERBY-2998) Add support for ROW_NUMBER() window function

2008-02-27 Thread Thomas Nielsen (JIRA)


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

Thomas Nielsen updated DERBY-2998:
--

Attachment: d2998-test8.diff
d2998-18.stat
d2998-18.diff

Attaching patch 18 and test8.

To Armys comments:
#1 - Patch 18 fixes the comment in allExpressionsAreColumns()
#2 - No, there are no tests that check this. This is a relic from cloning 
IndexToBaseRowNode. It should probably be removed?
#3 - Patch 18 relaxes the expectancy of finding RCL-WindowFunction, as well as 
generalizing the conditions throughout. This fixes the failing count() queries.

The test8 patch add all additional queries pointed to by army to the OLAPTest. 
All but the two last queries posted by Army pass, but I haven't had a chance to 
look at why yet. It is most likely connected to comment #3 though.

Army My experience with optimization/compilation is that VirtualColumnNodes, 
ResultColumns, and 
Army ColumnReferences are often stacked on top of each other in rather 
gratuitous fashion.

That's something I've obviously not taken well enough into consideration. Do 
you think that the approach I've taken is fundamentally flawed, or is it just 
being too restrictive?

 Add support for ROW_NUMBER() window function
 

 Key: DERBY-2998
 URL: https://issues.apache.org/jira/browse/DERBY-2998
 Project: Derby
  Issue Type: Sub-task
  Components: SQL
Reporter: Thomas Nielsen
Assignee: Thomas Nielsen
Priority: Minor
 Attachments: d2998-10.diff, d2998-10.stat, d2998-11.diff, 
 d2998-12.diff, d2998-12.stat, d2998-13.diff, d2998-13.stat, d2998-14.diff, 
 d2998-14.stat, d2998-15.diff, d2998-15.stat, d2998-16.diff, d2998-16.stat, 
 d2998-17.diff, d2998-17.stat, d2998-18.diff, d2998-18.stat, d2998-4.diff, 
 d2998-4.stat, d2998-5.diff, d2998-5.stat, d2998-6.diff, d2998-6.stat, 
 d2998-7.diff, d2998-7.stat, d2998-8.diff, d2998-8.stat, d2998-9-derby.log, 
 d2998-9.diff, d2998-9.stat, d2998-doc-1.diff, d2998-doc-1.stat, 
 d2998-test.diff, d2998-test.stat, d2998-test2.diff, d2998-test2.stat, 
 d2998-test3.diff, d2998-test3.stat, d2998-test4.diff, d2998-test4.stat, 
 d2998-test6.diff, d2998-test7.diff, d2998-test8.diff


 As part of implementing the overall OLAP Operations features of SQL 
 (DERBY-581), implement the ROW_NUMBER() window function.
 More information about this feature is available at 
 http://wiki.apache.org/db-derby/OLAPRowNumber

-- 
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

2008-02-27 Thread jira

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


Key Summary
DERBY-3460  SQL roles: patch to mask off roles on 10.4 release branch
https://issues.apache.org/jira/browse/DERBY-3460
DERBY-3441  Determine and implement a proper procedure for resetting a prepared 
statement for reuse in a statement pool
https://issues.apache.org/jira/browse/DERBY-3441
DERBY-3457  Closing a logical connection must close all associated logical 
statements
https://issues.apache.org/jira/browse/DERBY-3457
DERBY-3445  Make it easier to use the EMMA tool to measure the code coverage of 
the Derby testing
https://issues.apache.org/jira/browse/DERBY-3445
DERBY-3327  SQL roles: Implement authorization stack (and SQL session context 
to hold it)
https://issues.apache.org/jira/browse/DERBY-3327
DERBY-3205  Replication: Add connection url command options for starting, 
stopping slave and for failover
https://issues.apache.org/jira/browse/DERBY-3205
DERBY-3428  Doing a replication failover should shutdown the database and the 
connection should no longer be available
https://issues.apache.org/jira/browse/DERBY-3428
DERBY-3358  After an incorrect(unsuccesfull) startMaster comand, further 
correct startMaster attempts also fail.
https://issues.apache.org/jira/browse/DERBY-3358
DERBY-3448  Allow the MailJdbc system test to run under junit.
https://issues.apache.org/jira/browse/DERBY-3448
DERBY-3466  Investigate ability to run multiple Derby systems in same JVM with 
different sets of MBeans.
https://issues.apache.org/jira/browse/DERBY-3466
DERBY-3437  Give all replication threads meaningfull names
https://issues.apache.org/jira/browse/DERBY-3437
DERBY-3169  Add documentation for replication
https://issues.apache.org/jira/browse/DERBY-3169
DERBY-3310  ASSERT in MergeSort.checkColumnTypes() disallow legal type 
conversions
https://issues.apache.org/jira/browse/DERBY-3310
DERBY-3452  ShutdownException and ErrorStringBuilder classes do not belong to 
the services context module
https://issues.apache.org/jira/browse/DERBY-3452
DERBY-3388  Improve message handling for replication messages to derby.log
https://issues.apache.org/jira/browse/DERBY-3388
DERBY-3322  Server guide refers to phantom property in template policy file for 
the Network Server
https://issues.apache.org/jira/browse/DERBY-3322
DERBY-3442  Reference Manual doesn't state limit on number of identity columns
https://issues.apache.org/jira/browse/DERBY-3442
DERBY-2871  XATransactionTest gets XaException: Error executing a 
XAResource.commit(), server returned XAER_PROTO.
https://issues.apache.org/jira/browse/DERBY-2871
DERBY-3409  Remove JDBC 2.0-specific topics from Reference Manual and merge 
implementation notes as needed
https://issues.apache.org/jira/browse/DERBY-3409
DERBY-3001  SYSTABLES documentation for TABLETYPE should include 'A' (Synonym)
https://issues.apache.org/jira/browse/DERBY-3001
DERBY-3329  Enable statement pooling in the client JDBC driver
https://issues.apache.org/jira/browse/DERBY-3329
DERBY-3379  No Current connection on PooledConnection.getConnection() if 
pooled connection is reused during connectionClosed processing
https://issues.apache.org/jira/browse/DERBY-3379
DERBY-3014  Make 
SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.username')  return NULL 
instead of the hash value of the password
https://issues.apache.org/jira/browse/DERBY-3014
DERBY-2954  Add commands to NetworkServerControl for interacting with the 
replication functionality
https://issues.apache.org/jira/browse/DERBY-2954
DERBY-2953  Dump the information about rollbacks of the global transaction 
(introduced in DERBY-2220 and DERBY-2432) to derby.log
https://issues.apache.org/jira/browse/DERBY-2953
DERBY-3227  Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227

[jira] Commented: (DERBY-3457) Closing a logical connection must close all associated logical statements

[
https://issues.apache.org/jira/browse/DERBY-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572969#action_12572969
]

Dyre Tjeldvoll commented on DERBY-3457:
---

Hi Kristian, I had a quick look at the patch, and I think it looks good.

Wrt. how to handle a failing close(), I'm wondering if Statement.close() can
ever fail with a recoverable error? If it can't (and I don't think it can),
then I think the current approach will work well. The cleanup is aborted, but
presumably neither the physical statement or even the physical connection will
be usable in this case, so a graceful bailout seems the best one can do...

I guess I don't fully understand your last comment. super.close() in CLC would
refer to LogicalConnection.close(), right? But this method does not close any
LogicalStatements, does it? It has a comment saying that it needs to do so, but
it doesn't do it, I think. Is that to avoid the failure?

Closing a logical connection must close all associated logical statements
-

Attachments: derby-3457-1a-stmt_closing.diff,
derby-3457-1a-stmt_closing.stat, derby-3457-1b-stmt_closing.diff,
derby-3457-1c-stmt_closing.diff, derby-3457-2a-stmt_registration.diff

--
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 631298 - Sun DBTG

2008-02-27 Thread Henri . Vandescheur

[Auto-generated mail]

*Daily* 631298/2008-02-26 18:01:05 MET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
0271271 072.11% derbyall
01023310233 0   1525.16% suitesAll
 linN+1
0271271 098.24% derbyall
01023310233 0   122.71% suitesAll
 sles
0271271 070.38% derbyall
01023310233 0   912.15% suitesAll
 sol
0271271 074.17% derbyall
   NA NA NANA   suitesAll
 solN+1
0271271 096.23% derbyall
01023310233 0   192.30% suitesAll
 sparc
0271271 065.23% derbyall
01023310233 0   363.05% suitesAll
 vista
0271271 092.24% derbyall
091809180 066.57% suitesAll
 w2003
0271271 095.83% derbyall
091809180 0   135.90% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-631298.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/631298_bySig.html 

*Jvm: 1.5*
 lin
0272272 071.50% derbyall
085138513 0   883.84% suitesAll
 linN+1
0272272 097.84% derbyall
085138513 0   117.28% suitesAll
 sles
0272272 069.94% derbyall
085138513 0   571.29% suitesAll
 sol
0272272 077.67% derbyall
085138513 0   846.38% suitesAll
 solN+1
0272272 087.87% derbyall
085138513 0   804.46% suitesAll
 sparc
0272272 065.95% derbyall
085138513 0   696.75% suitesAll
 vista
0272272 070.93% derbyall
074607460 0   396.88% suitesAll
 w2003
0272272 073.91% derbyall
074607460 0   259.49% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-631298.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/631298_bySig.html 

*Jvm: 1.4*
 lin
0269269 272.72% derbyall
084618461 0   803.44% suitesAll
 linN+1
0269269 298.25% derbyall
084618461 0   117.12% suitesAll
 sles
0269269 270.43% derbyall
084618461 0   527.57% suitesAll
 sol
0269269 277.05% derbyall
084618461 0   683.43% suitesAll
 solN+1
0269269 288.93% derbyall
084618461 0   753.35% suitesAll
 sparc
0269269 266.40% derbyall
084618461 0   706.20% suitesAll
 vista
0269269 270.72% derbyall
074087408 0   389.67% suitesAll
 w2003
0269269 274.96% derbyall
074127412 0   251.51% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-631298.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/631298_bySig.html 

---

Changes in  http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/631298.txt 

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

[jira] Updated: (DERBY-2109) System privileges


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

Martin Zaun updated DERBY-2109:
---

Attachment: DERBY-2109-10.diff
DERBY-2109-10.stat

Please find attached patch update DERBY-2109-10 (replacing DERBY-2109-09):

a) Fixed AuthenticationTest (and other) failures; junit-all and derbyall run 
fine with the patch on my machine.

b) Made the System Privileges checks only dependent upon the presence of a 
SecurityManager, not upon Authentication, per derby-dev discussion JMX meeting 
system authorization (DERBY-2109  1387).

c) Moved class SecurityUtil from o.a.d.security to o.a.d.iapi.security, per 
suggestion by Dan.

d) Investigated an issue with non-normalized names in policy files where a 
grant to user edWard would not give permissions to the authenticated users 
edward or EDWARD but edWard only.

Bottomline: When evaluating permissions, the (Sun) Java Security Runtime uses 
the principal names as found literally in the policy file and not as returned 
by SystemPrincipal.getName() (where we could return normalized names).

As a workaround, our class SystemPrincipal could implement the non-standard 
interface com.sun.security.auth.PrincipalComparator, which declares a method 
implies(Subject) that allows for Principals to match Subjects based on 
normalized Authorization Identifiers, e.g., a policy grant  to edWard would 
give permissions to all users edWard, edward, and EDWARD.  But then we'd be 
relying upon a non-standard Security Runtime class and behaviour.  (Yet another 
approach would be to construct the Subject with a Principal list having all 
lower/upper case combinations of an identifier, but that's clearly not 
feasible.)

I changed classes SecurityUtil and SystemPrincipal and added javadoc comments 
reflecting that
- SystemPrincipal names are not Authorization Identifiers (i.e., non-delimited 
identifiers handled case-insensitively by magic of SystemPrincipal);
- SecurityUtil constructs a Subject with two SystemPrincipals: one with the 
literal user name and another with the normalized name.

For users who want to put specific principal grants into customized policy 
files this means:
- a grant to a principal named EDWARD gives permissions to all users edward, 
edWard, and EDWARD (and all other lower/upper case spellings);
- a grant to principal edWard only gives permissions to the user edWard.

In my view that's still an acceptable and documentable behaviour; but as said, 
I haven't found any other feasible workaround lifting the Java Security 
Runtime's literal handling of principal names.

e) Added comments to SystemPrivilegesPermissionTest.java on the use of 
Subject.doAsPrivileged() versus doAs() after further experiments with the Java 
Security Runtime.  Bottomline: doAsPrivileged() is the only implementation 
option for our purposes.

f) The patch does not reflect the latest suggestions by Dan for the shutdown 
permission following a new naming scheme (wanted to get this patch out and 
tested first).  But will look into it and comment.

Martin


 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via

[jira] Commented: (DERBY-3457) Closing a logical connection must close all associated logical statements

[
https://issues.apache.org/jira/browse/DERBY-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572987#action_12572987
]

Kristian Waagan commented on DERBY-3457:

Thanks for the review Dyre!

I basically agree with you on the close failure issue, but I can't say I'm 100%
sure. Unless someone gives me pushback, I think I'll stick with the current
approach (bailing out on first exception thrown).

My last comment was rooted in the code comment that you also noticed.
I need to verify what is actually happening. I see a few scenarios:
1) LogicalConnection actually closes the statements somehow, rendering the
statement pooling almost useless.
2) LogicalConnection does not close statements at all, and I'll log a bug in
JIRA.
This would affect environments using connection pooling (CP, XA), but not
statement pooling.

Solution to (1) *could* be to introduce a second close method, one that does
not close the statements (that would instead happen when you close the
PooledConnection). The comment should be removed.
For (2), a mechanism must be put into place and the comment can be removed.
Maybe we can use / come up with a shared mechanism for LC and CLC, I don't know
yet. Maybe even something in am.Connection can be used, I know it keeps track
of statements it creates.

I'll get back with more information later, hopefully tomorrow.

Closing a logical connection must close all associated logical statements
-

Attachments: derby-3457-1a-stmt_closing.diff,
derby-3457-1a-stmt_closing.stat, derby-3457-1b-stmt_closing.diff,
derby-3457-1c-stmt_closing.diff, derby-3457-2a-stmt_registration.diff

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

Re: 10.4 Feature Freeze

2008-02-27 Thread Daniel John Debrunner


Rick Hillegas wrote:

Daniel John Debrunner wrote:


I'm trying to add Java security manager checks (DERBY-3462) to the JMX 
MBeans so that security is not compromised by the addition of JMX. 
While I'm not blocked by DERBY-2109, if I proceed ahead of DERBY-2019 
committing code JMX related permission code then any DERBY-2109 patch 
will have to re-worked again. However since there doesn't seem to be 
any activity on DERBY-2109 I may just go ahead anyway.


Dan.
Please do not do this, at least not in a way which will make it 
necessary to rework and retest DERBY-2109.


I'll avoid doing this, I think there is a temp workaround I can do. If 
we get to the branch cutoff though without any progress on DERBY-2109 
then changes may need to be made.


Martin is actively working on 
this feature and deserves our patience and respect.


That's great, but you have to look at it from the issue of activity on 
the list: Given no messages for over two weeks from any contributor 
there are a number of scenarios one can imagine from not being active on 
derby anymore to being stuck on a problem that the community could 
possibly help with. Without communication it's impossible to tell so one 
has to assume not active if one wants to fry a fish in the same or 
overlapping area.



Each rework/retest cycle is turning out to be very expensive.


Is there a way the community could help, posting a newer version of the 
patch, helping solve issues, running the tests on various platforms?


I think this patch would have benefited from continuing the incremental 
development approach it started with. The current patch is trying to 
solve at least four issues. With an incremental approach my opinion is 
that most of the current patch's functionality could have already been 
committed, allowing focus on specific problems and a quicker turn-around 
on testing etc. I wonder if some folks are reluctant to perform 
incremental development because they think patches are too slow to be 
applied, thus they do a mega-patch which of course will take time to 
commit, thus we have a self-fulfilling prophecy?


Dan.

[jira] Resolved: (DERBY-3328) Extend client JDBC object factory with methods to create objects required for statement pooling


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

Kristian Waagan resolved DERBY-3328.


Resolution: Fixed

I believe the required work has been done for this issue.

 Extend client JDBC object factory with methods to create objects required for 
 statement pooling
 ---

 Key: DERBY-3328
 URL: https://issues.apache.org/jira/browse/DERBY-3328
 Project: Derby
  Issue Type: Sub-task
  Components: Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: derby-3328-1a-extend_jdbc_objectfactories.diff, 
 derby-3328-1a-extend_jdbc_objectfactories.stat, 
 derby-3328-2a-change_signatures.diff, derby-3328-2a-change_signatures.stat


 Since statement pooling introduces new types of objects, the factories must 
 be extended to handle these new types.
 This step is primarily required because we support multiple versions of the 
 JDBC standard, which in turn implies running with different interfaces and 
 JVM versions with differing features.

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

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572991#action_12572991
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

 Bottomline: When evaluating permissions, the (Sun) Java Security Runtime uses 
 the principal names as found literally in the policy file and not as returned 
 by SystemPrincipal.getName() (where we could return normalized names). 

It's hard to see how that is the case, since the policy file is read in and 
converted to a Policy object containing permissions and for Derby's 
SystemPermission the class must be o.a.d.security.SystemPermission.

Could you confirm the format for names in the policy file in the patch? Does it 
match 


 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
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-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572991#action_12572991
 ] 

djd edited comment on DERBY-2109 at 2/27/08 9:27 AM:
---

 Bottomline: When evaluating permissions, the (Sun) Java Security Runtime uses 
 the principal names as found literally in the policy file and not as returned 
 by SystemPrincipal.getName() (where we could return normalized names). 

It's hard to see how that is the case, since the policy file is read in and 
converted to a Policy object containing permissions and for Derby's 
SystemPermission the class must be o.a.d.security.SystemPermission.

Could you confirm the format for names in the policy file in the patch? Does it 
match the description here:
https://issues.apache.org/jira/browse/DERBY-2109?focusedCommentId=12561537#action_12561537

 - does it support delimited identifiers of the form \[EMAIL PROTECTED]?
 - is the only issue that non-delimited identifiers fred do not resolve 
correctly?

  was (Author: djd):
 Bottomline: When evaluating permissions, the (Sun) Java Security Runtime 
uses the principal names as found literally in the policy file and not as 
returned by SystemPrincipal.getName() (where we could return normalized names). 

It's hard to see how that is the case, since the policy file is read in and 
converted to a Policy object containing permissions and for Derby's 
SystemPermission the class must be o.a.d.security.SystemPermission.

Could you confirm the format for names in the policy file in the patch? Does it 
match 

  
 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.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-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573003#action_12573003
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

I'm prepared to commit this patch but I think there are a number of follow 
changes that would need to be done before a 10.4 release is made. I guess if 
it's committed to trunk then it can always be backed out from the branch if it 
doesn't seem ready for release.

 - figuring out the principal names in the policy files - I'd be interested to 
see the implementation of SystemPrincipal you used to try and implement the 
required functionality

 - related to the previous one is having more time to understand this:
+// An alternative approach of normalizing all names within
+// SystemPrincipal has issues; see comments there.
+principals.add(new SystemPrincipal(user));
+principals.add(new SystemPrincipal(getAuthorizationId(user)));

From a security point of view does this have the potential to allow one user 
to piggy back on the permissions of another user?

 - ensuring the new security objects that are serializable have serialization 
ids to ensure compatibility across releases

 - making the  new security objects final

Thanks for working on the functionality through many patches!

 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.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-3304) Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable

2008-02-27 Thread Mamta A. Satoor (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573002#action_12573002
 ] 

Mamta A. Satoor commented on DERBY-3304:


Number of fixes have gone in this jira entry and I think I have tackled all the 
issues related to this jira entry through them. The only thing I am aware of is 
that revisions 629926 and 631481 from trunk have not been merged into 10.3 
codeline because they depend on merge of fix for DERBY-3404 into 10.3 and that 
merge is running into locking issues.

If I have missed any other issue on this jira entry, please let me know.

 Explicit commit inside a java procedure makes a dynamic result sets passed 
 out unavailable
 --

 Key: DERBY-3304
 URL: https://issues.apache.org/jira/browse/DERBY-3304
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.4.0.0
Reporter: Daniel John Debrunner
Assignee: Mamta A. Satoor
 Attachments: Main.java


 Repro (Main.java) that shows changed behavior after svn 602991
 (the patch committed for this issue). It seems a regression: (originally from 
 Dag H. Wanvik attached to DERBY-1585)
 An explicit commit inside a stored procedure makes a dynamic result sets 
 passed out unavailable, even if the commit is executed *prior* to the result 
 set; as in the repro.

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

Re: [jira] Updated: (DERBY-3456) Allow removing not null from collumns particpating in unique constraint.

could you add the following tests:

o) just cover all the create index cases to make sure all the format id
btree code gets exercised. Some cases may not be affected by your code
but would be good to verify. Also by having all these cases I think
it will cover all the stored format paths for the new format stuff in
the btree container.

1) create and use unique index (nullable and non-nullable),
non-unique index (nullable and non-nullable), non-null constraint in 10.3.
2) create and use unique index (nullable and non-nullable),
non-unique index (nullable and non-nullable), non-null constraint

in 10.4 soft upgrade.
3) create and use unique index (nullable and non-nullable),
non-unique index (nullable and non-nullable), unique constraint
(nullable and non-nullable)

in 10.4 hard upgrade, verify their null handling is as expected.
4) In 10.4 soft upgrade, access and use those indexes created in step
1, verify their null handling is as expected.
5) In 10.4 hard upgrade, access and use those indexes created in step
1, verify their null handling is as expected.
6) In 10.4 hard upgrade, access and use those indexes created in step
2, verify their null handling is as expected.

hopefully one routine can be reused for all of the above and just add
calls for each case, but with different index names for each case. By
verify expected behavior I mean:

unique nullable index - only one null allowed
unique non-nullable index - no null allowed
non-unique index (nullable) - multiple nulls allowed
non-unique index (non-nullable) - no nulls allowed
non-nullable constraint - no nulls allowed
nullable constraint - multiple nulls allowed

I don't know if the upgrade framework supports this, but you should at
least by hand test at least once that you can access all the above after

you shutdown the database and then access it again. Some of the upgrade
code only will get exercised if the index is accessed for the first
time, as the contain information is otherwise cached. It is important
to test that the new formatid stuff is being read from DISK correctly.

Also how have you been testing your retry code?

Anurag Shekhar (JIRA) wrote:

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

Anurag Shekhar updated DERBY-3456:
--

Attachment: upgradetests.diff

This patch has upgrade tests for unique constraint.

under soft upgrade
1. Setting columns from unique constraint to null able - should fail
2. creation of unique constraint over nullable columns - should fail
3. creation of unique constraint over not null column - should pass

under post soft upgrade
test unique constraint created in soft upgrade phase.

under hard upgrade
1. Tests unique constraint creation prior to upgrade
2. Tests unique constraint over null able columns - should pass
3. Test setting column from unique constraint to null able - should pass

Allow removing not null from collumns particpating in unique constraint.

Key: DERBY-3456
URL: https://issues.apache.org/jira/browse/DERBY-3456
Project: Derby
Issue Type: Sub-task
Components: SQL, Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: derby-3456v1.diff, upgradetests.diff

[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function


[ 
https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573011#action_12573011
 ] 

A B commented on DERBY-2998:


 Do you think that the approach I've taken is fundamentally flawed, or is it 
 just being too restrictive?

No, I do not think it's flawed.  And I can't say with any certainty that it's 
too restrictive, either, as I haven't actually found any cases which prove 
that.  Maybe the failing queries I posted above fall into that category, maybe 
not--I haven't done any detailed tracing.  I thought I'd mention it as 
something which made me uneasy, but it could very well be fine as it is.

 #3 - Patch 18 relaxes the expectancy of finding RCL-WindowFunction, as well 
 as generalizing
 the conditions throughout. This fixes the failing count() queries.

I like the additional methods to distinguish between how/where to look for the 
WindowFunctionColumnNode. Now the trick is to figure out which methods to call 
where :) My suggestion is that whenever you call any of these methods, try to 
determine if a comment indicating why you chose the method you did would be 
useful to the reader.  And that's especially true if you find yourself 
switching from one method to another at any point...

Side note: looks like the new isReferenceToOrWindowFunction() for patch 18 is 
never actually called anywhere. Was that intentional?

 Add support for ROW_NUMBER() window function
 

 Key: DERBY-2998
 URL: https://issues.apache.org/jira/browse/DERBY-2998
 Project: Derby
  Issue Type: Sub-task
  Components: SQL
Reporter: Thomas Nielsen
Assignee: Thomas Nielsen
Priority: Minor
 Attachments: d2998-10.diff, d2998-10.stat, d2998-11.diff, 
 d2998-12.diff, d2998-12.stat, d2998-13.diff, d2998-13.stat, d2998-14.diff, 
 d2998-14.stat, d2998-15.diff, d2998-15.stat, d2998-16.diff, d2998-16.stat, 
 d2998-17.diff, d2998-17.stat, d2998-18.diff, d2998-18.stat, d2998-4.diff, 
 d2998-4.stat, d2998-5.diff, d2998-5.stat, d2998-6.diff, d2998-6.stat, 
 d2998-7.diff, d2998-7.stat, d2998-8.diff, d2998-8.stat, d2998-9-derby.log, 
 d2998-9.diff, d2998-9.stat, d2998-doc-1.diff, d2998-doc-1.stat, 
 d2998-test.diff, d2998-test.stat, d2998-test2.diff, d2998-test2.stat, 
 d2998-test3.diff, d2998-test3.stat, d2998-test4.diff, d2998-test4.stat, 
 d2998-test6.diff, d2998-test7.diff, d2998-test8.diff


 As part of implementing the overall OLAP Operations features of SQL 
 (DERBY-581), implement the ROW_NUMBER() window function.
 More information about this feature is available at 
 http://wiki.apache.org/db-derby/OLAPRowNumber

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

[jira] Commented: (DERBY-3192) Cache session data in the client driver

[
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573013#action_12573013
]

Dyre Tjeldvoll commented on DERBY-3192:
---

I have updated the writeup so that it matches the committed patch. When doing
that it occurred to me that I should probably remove the special handling of
SYNCCTL in my sanity ASSERT at the bottom of the processCommands-switch. I'll
upload a follow-up patch when I've tested it.

Cache session data in the client driver
---

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

[jira] Commented: (DERBY-3456) Allow removing not null from collumns particpating in unique constraint.


[ 
https://issues.apache.org/jira/browse/DERBY-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573017#action_12573017
 ] 

A B commented on DERBY-3456:


When creating the backing index for a constraint, Derby currently attempts to 
share conglomerates if there is an existing conglomerate such that:

  1. the set of columns and their order in the constraint-backing index is the 
same
as that of an existing index AND

  2. the ordering attributes are the same AND

  3. both the already-existing index and the constraint-backing index being 
created
are non-unique OR the already existing index is unique

If all three of these conditions are true then Derby will use a single physical 
conglomerate to support the already-existing index and the new 
constraint-backing index.

So my question is: when unique constraints over nullable columns are 
introduced, will this criteria (found in CreateIndexConstantAction.java; search 
for shareExisting) need to be updated?  In particular, I'm wondering if #3 is 
still good enough, or will additional logic for nullable unique constraints 
need to be added?

 Allow removing not null from collumns particpating in unique constraint.
 

 Key: DERBY-3456
 URL: https://issues.apache.org/jira/browse/DERBY-3456
 Project: Derby
  Issue Type: Sub-task
  Components: SQL, Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: derby-3456v1.diff, upgradetests.diff




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

[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function

2008-02-27 Thread Thomas Nielsen (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573018#action_12573018
 ] 

Thomas Nielsen commented on DERBY-2998:
---

Thanks Army. Good to hear it's not all wrong :)

 Side note: looks like the new isReferenceToOrWindowFunction() for patch 18 
 is never actually called anywhere. Was that intentional?
Yes :)

 Add support for ROW_NUMBER() window function
 

 Key: DERBY-2998
 URL: https://issues.apache.org/jira/browse/DERBY-2998
 Project: Derby
  Issue Type: Sub-task
  Components: SQL
Reporter: Thomas Nielsen
Assignee: Thomas Nielsen
Priority: Minor
 Attachments: d2998-10.diff, d2998-10.stat, d2998-11.diff, 
 d2998-12.diff, d2998-12.stat, d2998-13.diff, d2998-13.stat, d2998-14.diff, 
 d2998-14.stat, d2998-15.diff, d2998-15.stat, d2998-16.diff, d2998-16.stat, 
 d2998-17.diff, d2998-17.stat, d2998-18.diff, d2998-18.stat, d2998-4.diff, 
 d2998-4.stat, d2998-5.diff, d2998-5.stat, d2998-6.diff, d2998-6.stat, 
 d2998-7.diff, d2998-7.stat, d2998-8.diff, d2998-8.stat, d2998-9-derby.log, 
 d2998-9.diff, d2998-9.stat, d2998-doc-1.diff, d2998-doc-1.stat, 
 d2998-test.diff, d2998-test.stat, d2998-test2.diff, d2998-test2.stat, 
 d2998-test3.diff, d2998-test3.stat, d2998-test4.diff, d2998-test4.stat, 
 d2998-test6.diff, d2998-test7.diff, d2998-test8.diff


 As part of implementing the overall OLAP Operations features of SQL 
 (DERBY-581), implement the ROW_NUMBER() window function.
 More information about this feature is available at 
 http://wiki.apache.org/db-derby/OLAPRowNumber

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

Re: [jira] Updated: (DERBY-3456) Allow removing not null from collumns particpating in unique constraint.

Thanks Mike for looking at the issue. I will update the upgrade
testcases with the tests you have suggested.
I am not sure what you mean by retry code. Do you mean the situation
where rescanning of BTree is required to identify the slot to insert ? I
was testing it with 2 ij windows. I have also written a test case for it
and attached to DERBY-3473
(https://issues.apache.org/jira/browse/DERBY-3473).

anurag

Mike Matrigali wrote:

could you add the following tests:

o) just cover all the create index cases to make sure all the format
id btree code gets exercised. Some cases may not be affected by your
code but would be good to verify. Also by having all these cases I think
it will cover all the stored format paths for the new format stuff in
the btree container.

1) create and use unique index (nullable and non-nullable),
non-unique index (nullable and non-nullable), non-null constraint in
10.3.
2) create and use unique index (nullable and non-nullable),
non-unique index (nullable and non-nullable), non-null constraint

in 10.4 soft upgrade.
3) create and use unique index (nullable and non-nullable),
non-unique index (nullable and non-nullable), unique constraint
(nullable and non-nullable)

hopefully one routine can be reused for all of the above and just add
calls for each case, but with different index names for each case. By
verify expected behavior I mean:

I don't know if the upgrade framework supports this, but you should at
least by hand test at least once that you can access all the above after

Also how have you been testing your retry code?

Anurag Shekhar (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Anurag Shekhar updated DERBY-3456:
--

Attachment: upgradetests.diff

This patch has upgrade tests for unique constraint.

under post soft upgrade
test unique constraint created in soft upgrade phase.

Allow removing not null from collumns particpating in unique
constraint.

Re: 10.4 Feature Freeze

2008-02-27 Thread Dyre Tjeldvoll


Anurag Shekhar wrote:

[EMAIL PROTECTED] wrote:

... is fast approaching (2008-02-29)

Is this still a reasonable date, or should we consider delaying it?



Unique constraints   On track
  
I have all the patches (3 of them) in jira and there are chances that 
they might get commited before 29th but having one more week in hand 
will be lot more comfortable.


Ok, noted.

Also I would like write a couple of multi threaded tests to test locking 
behavior of unique constraint.


Sounds like a good idea, :)

Dyre

Re: 10.4 Feature Freeze

2008-02-27 Thread Dyre Tjeldvoll


Knut Anders Hatlen wrote:

[EMAIL PROTECTED] writes:


... is fast approaching (2008-02-29)

Is this still a reasonable date, or should we consider delaying it?


Here is the current status (based on what I know):

[...]

Buffer manager   On track


Hi Dyre,

The code for the buffer manager has been in the repository for quite
some time now, but it has not yet been enabled in
modules.properties. Øystein has reviewed the code and suggested some
improvements. I'll probably not have the time to make all the changes
Øystein suggested before the feature freeze date, but since the
improvements are mainly reorganizing some methods and improving the
comments, I think we could just as well enable it now before the
improvements have been made. I have just asked about it on JIRA, and
I'll wait until someone says go ahead before I enable it.



Ok, thanks for the update. Unless enabling it will make it difficult to 
address the review comments, I'd say go ahead.


Dyre

[jira] Updated: (DERBY-3330) provide support for unique constraint over nullable columns


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

Mike Matrigali updated DERBY-3330:
--


do you know why the master for dml019 changed?  
Index: java/testing/org/apache/derbyTesting/functionTests/master/dml019.out
===
--- java/testing/org/apache/derbyTesting/functionTests/master/dml019.out
(revision 630309)
+++ java/testing/org/apache/derbyTesting/functionTests/master/dml019.out
(working copy)
@@ -82,18 +82,18 @@
   GROUP BY PNUM,EMPNUM,HOURS;
 EM|PN|HOURS
 --
-E1 |P1 |40
-E1 |P2 |20
-E1 |P3 |80
-E1 |P4 |20
+E2 |P1 |40
+E4 |P4 |40
 E1 |P5 |12
+E4 |P5 |80
 E1 |P6 |12
-E2 |P1 |40
-E2 |P2 |80
 E3 |P2 |20
+E1 |P4 |20
+E1 |P1 |40
 E4 |P2 |20
-E4 |P4 |40
-E4 |P5 |80
+E1 |P2 |20
+E2 |P2 |80
+E1 |P3 |80
 ij -- PASS:0077 If 12 rows are selected ?

 -- END TEST  0077  END TEST
@@ -105,18 +105,18 @@
   GROUP BY EMPNUM,PNUM,HOURS;
 PN|EM
 ---
-P1 |E1
-P2 |E1
-P3 |E1
-P4 |E1
+P1 |E2
+P4 |E4
 P5 |E1
+P5 |E4
 P6 |E1
-P1 |E2
-P2 |E2
 P2 |E3
+P4 |E1
+P1 |E1
 P2 |E4
-P4 |E4
-P5 |E4
+P2 |E1
+P2 |E2
+P3 |E1
 ij -- PASS:0078 If 12 rows are selected  ?

 -- END TEST  0078  END TEST

 provide support for unique constraint over nullable columns
 ---

 Key: DERBY-3330
 URL: https://issues.apache.org/jira/browse/DERBY-3330
 Project: Derby
  Issue Type: New Feature
  Components: Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: BTreeController.diff, derby-3330-testcase.diff, 
 derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff, 
 derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, derby-3330v8.diff, 
 derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html, 
 FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html, 
 UniqueConstraint_Implementation_V2.html, 
 UniqueConstraint_Implementation_V3.html


 Allow unique constraint over nullable field. Right now derby support unique 
 constraint only over not null columns.

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

[jira] Commented: (DERBY-3456) Allow removing not null from collumns particpating in unique constraint.


[ 
https://issues.apache.org/jira/browse/DERBY-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573031#action_12573031
 ] 

Anurag Shekhar commented on DERBY-3456:
---

After applying 3330. A unique constraint won't be using a unique index 
but will use a  non unique backing  index with special case of 
uniqueWhenNotNull. So Case 3 needs to modified.
Thanks for pointing out.

There is one more minor change in CreateIndexConstantAction required (to 
fetch new attribute uniqueWhenNotNull) while creating a replacement index.
I will make these two changes in a separate patch.




 Allow removing not null from collumns particpating in unique constraint.
 

 Key: DERBY-3456
 URL: https://issues.apache.org/jira/browse/DERBY-3456
 Project: Derby
  Issue Type: Sub-task
  Components: SQL, Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: derby-3456v1.diff, upgradetests.diff




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

[jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns


[ 
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573032#action_12573032
 ] 

Anurag Shekhar commented on DERBY-3330:
---

dml019 test group by clause of unique constraint. When unique constraint 
was backed by unique index, distinct scan  was used but after making it non 
unique constraint this was not the case so the results are not ordered. 

I have checked the test suite from nist web site and it mandates only 
number of rows and not their sequence. 

 provide support for unique constraint over nullable columns
 ---

 Key: DERBY-3330
 URL: https://issues.apache.org/jira/browse/DERBY-3330
 Project: Derby
  Issue Type: New Feature
  Components: Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: BTreeController.diff, derby-3330-testcase.diff, 
 derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff, 
 derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, derby-3330v8.diff, 
 derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html, 
 FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html, 
 UniqueConstraint_Implementation_V2.html, 
 UniqueConstraint_Implementation_V3.html


 Allow unique constraint over nullable field. Right now derby support unique 
 constraint only over not null columns.

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

[jira] Closed: (DERBY-1368) EOFException when reading from blob's binary stream

2008-02-27 Thread Tobias Bocanegra (JIRA)


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

Tobias Bocanegra closed DERBY-1368.
---


thanks for fixing this.

 EOFException when reading from blob's binary stream
 ---

 Key: DERBY-1368
 URL: https://issues.apache.org/jira/browse/DERBY-1368
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.1.2.1
Reporter: Tobias Bocanegra
 Fix For: 10.2.1.6

 Attachments: derby-1368_diff.txt, derby-1368_diff2.txt, Derby1368.java


 reading the 'length()' of a blob reads a previously aquired binary stream.
 test case:
 public static void main(String[] argv) throws Exception {
 String driver = org.apache.derby.jdbc.EmbeddedDriver;
 String url = jdbc:derby:derby/test;create=true;
 Class.forName(driver);
 Connection con = DriverManager.getConnection(url, sa, );
 con.setAutoCommit(true);
 // create table
 System.out.println(1) creating table...);
 Statement stmt = con.createStatement();
 stmt.execute(create table T1 (ID char(32) PRIMARY KEY, DATA blob(2G) 
 not null));
 stmt.close();
 // add row
 System.out.println(2) adding row...);
 byte[] data = new byte[1024*1024*1];
 data[0] = 1;
 data[1] = 2;
 PreparedStatement s = con.prepareStatement(insert into T1 (ID, DATA) 
 values (?, ?));
 s.setString(1, id);
 s.setBytes(2, data);
 s.execute();
 s.close();
 // read row
 System.out.println(3) reading row...);
 s = con.prepareStatement(select DATA from T1 where ID = ?);
 s.setString(1, id);
 s.execute();
 ResultSet rs = s.getResultSet();
 rs.next();
 Blob b = rs.getBlob(1);
 // test output
 System.out.println(4) Length:  + b.length());
 InputStream in = b.getBinaryStream();
 System.out.println(   First Byte:  + in.read());
 in.close();
 in = b.getBinaryStream();
 System.out.println(5) Length:  + b.length());
 System.out.println(   First Byte:  + in.read());
 in.close();
 rs.close();
 s.close();
 con.close();
 }
 gives:
 1) creating table...
 2) adding row...
 3) reading row...
 4) Length: 1048576
First Byte: 1
 5) Length: 1048576
First Byte: -1
 imo, 5) is wrong.

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

[jira] Created: (DERBY-3476) Permissions and Principal objects added by this feature need to be final and have serialization identifiers

Permissions and Principal objects added by this feature need to be final and 
have serialization identifiers
---

 Key: DERBY-3476
 URL: https://issues.apache.org/jira/browse/DERBY-3476
 Project: Derby
  Issue Type: Sub-task
  Components: Security
Reporter: Daniel John Debrunner


Need serialization id to ensure the class is portable across releases.
Need final to provide security.

(assumes patch10 is committed from DERBY-2109)

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

[jira] Commented: (DERBY-3094) Grouping of expressions causes NullPointerException


[ 
https://issues.apache.org/jira/browse/DERBY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573053#action_12573053
 ] 

A B commented on DERBY-3094:


sortExpressions.diff looks good to me.  Thanks for continuing with that 
approach, Bryan.  Assuming derbyall and suites.All run cleanly, I say +1 to 
commit since it fixes all of the known queries and seems algorithmically 
correct as far as I can tell.  If additional issues/queries are discovered 
later, I think they can be addressed as they are found.

One nit: it seems the creation of a new ArrayList for havingRefsToSubstitute 
could be conditional upon the presence of a non-null havingClause, and that a 
single ExpressionSorter() could be used instead of two.  But in both cases the 
code may be easier to read as it is, so I'm not sure it's really worth 
changing...

 Grouping of expressions causes NullPointerException
 ---

 Key: DERBY-3094
 URL: https://issues.apache.org/jira/browse/DERBY-3094
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Windows XP, Eclipse 3.2.2, java 1.5.0.11
Reporter: Peter Balon
Assignee: Bryan Pendleton
Priority: Critical
 Attachments: d3094_followup.htm, modifyVisitorDoesntWork.diff, 
 notes.html, sortExpressions.diff, twoPass.diff, 
 TwoPassForHavingClauseAlso.diff, TwoPassVisitor.diff, 
 TwoPassVisitorWithCommentsAndTests.diff


 Following steps to reproduce the bug:
 create table xx (a double, b double);
 insert into xx values (2, 3);
 select a, a*(b/100.00), count(*) from xx  group by a, a*(b/100.00);
 Starting run
 select a, a*(b/100.00), count(*) from xx 
 group by a, a*(b/100.00)
 Run successful
 SQL State = 38000 SQL Code = 2 SQL Message = Bei der Auswertung eines 
 Ausdrucks wurde die Ausnahme 'java.lang.NullPointerException' ausgelöst. 
 Exception message = java.sql.SQLException: Bei der Auswertung eines Ausdrucks 
 wurde die Ausnahme 'java.lang.NullPointerException' ausgelöst.
 Work around:
 select a, a*(b/100.00), count(*) from xx group by a, b, a*(b/100.00) 
 Stack trace from application:
 java.sql.SQLException: Bei der Auswertung eines Ausdrucks wurde die Ausnahme 
 'java.lang.NullPointerException' ausgelöst.
   at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
   at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
 Source)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown 
 Source)
   at 
 org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
   at 
 de.arcor.billy.report.views.designer.ReportViewerView.setInput(ReportViewerView.java:255)
   at 
 de.arcor.billy.report.views.designer.ReportViewerView.createPartControl(ReportViewerView.java:113)
   at 
 org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332)
   at 
 org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197)
   at 
 org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
   at org.eclipse.ui.internal.Perspective.showView(Perspective.java:1675)
   at 
 org.eclipse.ui.internal.WorkbenchPage.busyShowView(WorkbenchPage.java:987)
   at 
 org.eclipse.ui.internal.WorkbenchPage.access$13(WorkbenchPage.java:968)
   at org.eclipse.ui.internal.WorkbenchPage$13.run(WorkbenchPage.java:3514)
   at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
   at 
 org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:3511)
   at 
 de.arcor.billy.report.data.ReportDataAdvisor$2.perspectiveChanged(ReportDataAdvisor.java:268)
   at 
 de.arcor.billy.system.actions.AbstractOpenPerspectiveActionDelegate$1.run(AbstractOpenPerspectiveActionDelegate.java:66)
   at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
   at 
 org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123)
   at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3325)
   at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971)
   at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1930)
   at

[jira] Created: (DERBY-3477) Make format principal names in SystemPermission (e.g. policy files) match the standard way Derby handles authorization identifiers in a Java context.

Make format principal names in SystemPermission (e.g. policy files) match the 
standard way Derby handles authorization identifiers in a Java context.
-

 Key: DERBY-3477
 URL: https://issues.apache.org/jira/browse/DERBY-3477
 Project: Derby
  Issue Type: Sub-task
  Components: Security
Reporter: Daniel John Debrunner


Expected format described in:

https://issues.apache.org/jira/browse/DERBY-2109?focusedCommentId=12561537#action_12561537
 

Comments in DERBY--2109 around patch 10 indicate some issue around implementing 
this, it would be good to see the code that attempted to implement it to help 
figure out the problem.

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

Re: [jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns

I thought from functional spec and ongoing discussion that behavior of 
unique constraint on non-nullable columns would be unchanged.  So this

constraint should still be backed by a unique index.

Anurag Shekhar (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573032#action_12573032 ] 


Anurag Shekhar commented on DERBY-3330:
---

dml019 test group by clause of unique constraint. When unique constraint 
was backed by unique index, distinct scan  was used but after making it non 
unique constraint this was not the case so the results are not ordered. 

I have checked the test suite from nist web site and it mandates only 
number of rows and not their sequence. 


provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
 Issue Type: New Feature
 Components: Store
   Affects Versions: 10.4.0.0
Environment: all
   Reporter: Anurag Shekhar
   Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330-testcase.diff, 
derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff, 
derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, derby-3330v8.diff, 
derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html, 
FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html, 
UniqueConstraint_Implementation_V2.html, UniqueConstraint_Implementation_V3.html


Allow unique constraint over nullable field. Right now derby support unique 
constraint only over not null columns.

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573057#action_12573057
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

Not sure the patch can be committed. The code uses javax.security classes which 
are not available on J2ME/CDC/Foundation.

I raised this earlier:

1) Since J2ME/CDC/Foundation does not support some of the security classes 
used, how is this being handled? Seems like it isn't at the moment. I think a 
new abstract method is needed in InternalDriver called shutdownCheck() is 
needed that would do nothing in J2ME but call the checks (through SecurityUtil 
in J2SE. 

https://issues.apache.org/jira/browse/DERBY-2109?focusedCommentId=12561087#action_12561087

Does the patch work currently on J2ME, I don't have any environment to check it 
out at the moment. If someone has a J2ME environment and try the patch and see 
if shutting down Derby works that would be a help.

 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

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

Re: [jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns

Unique constraint on non nullable fields still act like a unique index 
(because there is no null value) but internally they are backed by non 
unique indexes with uniqueWhenNotNull attribute.

anurag

Mike Matrigali wrote:
I thought from functional spec and ongoing discussion that behavior of 
unique constraint on non-nullable columns would be unchanged.  So this

constraint should still be backed by a unique index.

Anurag Shekhar (JIRA) wrote:
[ 
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573032#action_12573032 
]

Anurag Shekhar commented on DERBY-3330:
---

dml019 test group by clause of unique constraint. When unique 
constraint was backed by unique index, distinct scan  was used but 
after making it non unique constraint this was not the case so the 
results are not ordered.
I have checked the test suite from nist web site and it mandates only 
number of rows and not their sequence.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
 Issue Type: New Feature
 Components: Store
   Affects Versions: 10.4.0.0
Environment: all
   Reporter: Anurag Shekhar
   Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330-testcase.diff, 
derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff, 
derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff, 
derby-3330v7.diff, derby-3330v8.diff, derby-3330v9.diff, 
FunctionalSpec_DERBY-3330-V2.html, FunctionalSpec_DERBY-3330.html, 
UniqueConstraint_Implementation.html, 
UniqueConstraint_Implementation_V2.html, 
UniqueConstraint_Implementation_V3.html



Allow unique constraint over nullable field. Right now derby support 
unique constraint only over not null columns.

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573059#action_12573059
 ] 

Martin Zaun commented on DERBY-2109:



I'm sorry to say that I overlooked one line of debug code in SecurityUtil that 
made it into DERBY-2109-10. (I'd forgotten tagged that line as usual.)  
Unfortunately, the line is significant since the published code checks for a 
dummy permission I'd put in there for doAs() v. doAsPrivileged() debugging 
purposes:
+//AccessController.checkPermission(perm);
+AccessController.checkPermission(new 
java.util.PropertyPermission(user.dir, read));

I'm right now running junit-all (1 error) and will publish another patch update 
right after.

 Daniel John Debrunner wrote:
  Bottomline: When evaluating permissions, the (Sun) Java Security Runtime 
  uses the principal names as found literally in the policy file and not as 
  returned by SystemPrincipal.getName() (where we could return normalized 
  names).
 It's hard to see how that is the case, since the policy file is read in and 
 converted to a Policy object containing permissions and for Derby's 
 SystemPermission the class must be o.a.d.security.SystemPermission.

It's correct that we're using our SystemPermission classes only -- but the 
issue is in the realm of Subject/Principal checking by the Java Security 
Runtime when matching the Subject instantiated by our code against the 
Principal declaration in the policy file. This check is not entirely carried 
out by means of getName()/equals()/hashCode()  on our SystemPrincipal class, in 
which case we could have had the name comparisons always done on the normalized 
names.  Instead, the Java Security Runtime uses the literal Principal name as 
declared in the policy file and denies permission when it can't find an exact 
match in our Subject's SystemPrincipal list.

 - figuring out the principal names in the policy files - I'd be interested to 
 see the implementation of SystemPrincipal you used to try and implement the 
 required functionality 

The SystemPrincipal class in DERBY-2109-09 attempted to encapsulate 
Authorization Identifiers and normalized the principal name right within the 
constructor, so that getName()/equals()/hashCode()  would operate on 
(normalized) auth ids. 

As commented I also looked into SystemPrincipal implementing 
com.sun.security.auth.PrincipalComparator by adding an implies(Subject) method 
returning true when a the Subject's principal list contains a normalized name 
matching this principal's normalized name.  With a few more tricks I got it 
working -- but that was just for insight, since PrincipalComparator is a 
non-standard interface.

  - related to the previous one is having more time to understand this:
 + // An alternative approach of normalizing all names within
 + // SystemPrincipal has issues; see comments there.
 + principals.add(new SystemPrincipal(user));
 + principals.add(new SystemPrincipal(getAuthorizationId(user))); 

Adding the normalized identifier ensures that a non-delimited principal FRED 
matches users fred, Fred, FRED ...

Let me know if you think the code needs more comments.

 Could you confirm the format for names in the policy file in the patch? Does 
 it match the description here:
https://issues.apache.org/jira/browse/DERBY-2109?focusedCommentId=12561537#action_12561537
 - does it support delimited identifiers of the form \[EMAIL PROTECTED]?

yes

 - is the only issue that non-delimited identifiers fred do not resolve 
 correctly?

They resolve incompletely: non-delimited identifies fred only matches fred, 
while FRED matches fred, Fred, FRED ...

Here's what I've verified.  A policy file with belows grants results in the 
following System Privileges behaviour for users:

  grant principal org.apache.derby.authentication.SystemPrincipal MARTIN { 
... }
  checks for users:
 martin -- granted
 marTin -- granted
 MARTIN -- granted
 marTin -- denied, missing permission  (delimited identifier, different 
from marTin)

  grant principal org.apache.derby.authentication.SystemPrincipal edWard { 
... }
  checks for users:
edWard -- granted
edward -- denied, missing permission

  grant principal org.apache.derby.authentication.SystemPrincipal \[EMAIL 
PROTECTED] { ... }
  checks for users:
[EMAIL PROTECTED] -- granted
[EMAIL PROTECTED] -- denied, missing permission
[EMAIL PROTECTED] -- denied, illegally formed name as complained by 
IdUtil.getUserAuthorizationId() because it's a non-delimited identifier having 
special characters

However, in the last case the exception is not nicely presented to the client 
and needs improvement (I'd expected this case not to pass authentication, but 
we have to cover for it, especially since we now can have authorization checks 
without prior authentication).

 From a security point of view

Re: [jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns

Neighter the sql spec nor the derby manual promises this behavior 
(ordering of group by
clause without order by). So I don't think this is a deviation from the 
existing behavior.

anurag
Anurag shekhar wrote:
Unique constraint on non nullable fields still act like a unique index 
(because there is no null value) but internally they are backed by non 
unique indexes with uniqueWhenNotNull attribute.

anurag

Mike Matrigali wrote:
I thought from functional spec and ongoing discussion that behavior 
of unique constraint on non-nullable columns would be unchanged.  So 
this

constraint should still be backed by a unique index.

Anurag Shekhar (JIRA) wrote:
[ 
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573032#action_12573032 
]

Anurag Shekhar commented on DERBY-3330:
---

dml019 test group by clause of unique constraint. When unique 
constraint was backed by unique index, distinct scan  was used but 
after making it non unique constraint this was not the case so the 
results are not ordered.
I have checked the test suite from nist web site and it mandates 
only number of rows and not their sequence.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
 Issue Type: New Feature
 Components: Store
   Affects Versions: 10.4.0.0
Environment: all
   Reporter: Anurag Shekhar
   Assignee: Anurag Shekhar
Attachments: BTreeController.diff, 
derby-3330-testcase.diff, derby-3330.diff, derby-3330v2.diff, 
derby-3330v3.diff, derby-3330v4.diff, derby-3330v5.diff, 
derby-3330v6.diff, derby-3330v7.diff, derby-3330v8.diff, 
derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html, 
FunctionalSpec_DERBY-3330.html, 
UniqueConstraint_Implementation.html, 
UniqueConstraint_Implementation_V2.html, 
UniqueConstraint_Implementation_V3.html



Allow unique constraint over nullable field. Right now derby 
support unique constraint only over not null columns.

Re: [jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns

This is not what I thought was going to happen. For backward
compatibility (both performance, regression possibility and behavior),
why change the implementation of unique non-nullable constraints, to

use a non-unique index?
Especially at the very end of the code freeze cycle. I am ok with
moving forward on this if only constraints that could not be created
before this change use the new code, but if all constraints use the
new code then a lot more time/testing is needed. By incrementally
enabling the new code for the new indexes we can address bugs
as they come up but they are unlikely to be regressions in existing
applications.

I don't know what the performance degredation will be, but it can come
in many forms:
o just added code path for using non-unique index
o bad/different statistics for using non-unique index for unique
nonnullable constraint, leading to different query plans.
o more disk space required and longer insert times because now more
indexes are needed because the physical/logical index optimization does
not apply as a different index is being used for non-nullable unique
constraint.

o future index optimization may not apply, there are some compression
techniques that lend themselves better to unique indexes vs. non-unique.
o others i have not thought of.

Anurag shekhar wrote:
Unique constraint on non nullable fields still act like a unique index
(because there is no null value) but internally they are backed by non
unique indexes with uniqueWhenNotNull attribute.

anurag

Mike Matrigali wrote:
I thought from functional spec and ongoing discussion that behavior of
unique constraint on non-nullable columns would be unchanged. So this

constraint should still be backed by a unique index.

Anurag Shekhar (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573032#action_12573032
]

Anurag Shekhar commented on DERBY-3330:
---

dml019 test group by clause of unique constraint. When unique
constraint was backed by unique index, distinct scan was used but
after making it non unique constraint this was not the case so the
results are not ordered.
I have checked the test suite from nist web site and it mandates only
number of rows and not their sequence.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
Issue Type: New Feature
Components: Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330-testcase.diff,
derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff,
derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff,
derby-3330v7.diff, derby-3330v8.diff, derby-3330v9.diff,
FunctionalSpec_DERBY-3330-V2.html, FunctionalSpec_DERBY-3330.html,
UniqueConstraint_Implementation.html,
UniqueConstraint_Implementation_V2.html,
UniqueConstraint_Implementation_V3.html

Allow unique constraint over nullable field. Right now derby support
unique constraint only over not null columns.

new build and javadoc warnings

2008-02-27 Thread Kathey Marsden


Docs:
	  Failed with following errors. 
		  [javadoc] C:\nightlies\main\src\opensource\java\testing\org\apache\derbyTesting\functionTests\tests\management\MBeanTest.java:234: warning - @return tag has no arguments.

  [javadoc] 1 warning
Build:
	  Failed with following errors. 
		[javac] Note: C:\nightlies\main\src\opensource\java\testing\org\apache\derbyTesting\functionTests\tests\management\MBeanTest.java uses unchecked or unsafe operations.

[javac] Note: 
C:\nightlies\main\src\opensource\java\testing\org\apache\derbyTesting\functionTests\tests\management\MBeanTest.java
 uses unchecked or unsafe operations.

Re: [jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns

I will make the changes and upload a new patch.
anurag
Mike Matrigali wrote:
This is not what I thought was going to happen. For backward
compatibility (both performance, regression possibility and behavior),
why change the implementation of unique non-nullable constraints, to

o future index optimization may not apply, there are some compression
techniques that lend themselves better to unique indexes vs.
non-unique.

o others i have not thought of.

Anurag shekhar wrote:
Unique constraint on non nullable fields still act like a unique
index (because there is no null value) but internally they are backed
by non unique indexes with uniqueWhenNotNull attribute.

anurag

Mike Matrigali wrote:
I thought from functional spec and ongoing discussion that behavior
of unique constraint on non-nullable columns would be unchanged. So
this

constraint should still be backed by a unique index.

Anurag Shekhar (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573032#action_12573032
]

Anurag Shekhar commented on DERBY-3330:
---

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
Issue Type: New Feature
Components: Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: BTreeController.diff,
derby-3330-testcase.diff, derby-3330.diff, derby-3330v2.diff,
derby-3330v3.diff, derby-3330v4.diff, derby-3330v5.diff,
derby-3330v6.diff, derby-3330v7.diff, derby-3330v8.diff,
derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html,
FunctionalSpec_DERBY-3330.html,
UniqueConstraint_Implementation.html,
UniqueConstraint_Implementation_V2.html,
UniqueConstraint_Implementation_V3.html

Allow unique constraint over nullable field. Right now derby
support unique constraint only over not null columns.

[jira] Updated: (DERBY-3456) Allow removing not null from collumns particpating in unique constraint.


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

Anurag Shekhar updated DERBY-3456:
--

Attachment: upgradetests_v2.diff

This patch contains additional tests to test indexes created at various phases 
of upgrades. 
It creates a set of indexes (unique and non unique with null able and not null 
columns) and tests in others phases. 

 Allow removing not null from collumns particpating in unique constraint.
 

 Key: DERBY-3456
 URL: https://issues.apache.org/jira/browse/DERBY-3456
 Project: Derby
  Issue Type: Sub-task
  Components: SQL, Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: derby-3456v1.diff, upgradetests.diff, 
 upgradetests_v2.diff




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

[jira] Updated: (DERBY-3330) provide support for unique constraint over nullable columns

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

Mike Matrigali updated DERBY-3330:
--

I am running a set of tests on the v9 patch and will post results when they are
done. I am reviewing the v9 patch currently, but will likely concentrate on
the store level changes. If there is anyone with time to review the language
level code that would be good. Especially would like help verifying that the
language catalog upgrade code looks right - I have not done that before.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
Issue Type: New Feature
Components: Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330-testcase.diff,
derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff,
derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, derby-3330v8.diff,
derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html,
FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html,
UniqueConstraint_Implementation_V2.html,
UniqueConstraint_Implementation_V3.html

Allow unique constraint over nullable field. Right now derby support unique
constraint only over not null columns.

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

Re: 10.4 Feature Freeze

2008-02-27 Thread Rick Hillegas


Daniel John Debrunner wrote:

Rick Hillegas wrote:

Daniel John Debrunner wrote:


I'm trying to add Java security manager checks (DERBY-3462) to the 
JMX MBeans so that security is not compromised by the addition of 
JMX. While I'm not blocked by DERBY-2109, if I proceed ahead of 
DERBY-2019 committing code JMX related permission code then any 
DERBY-2109 patch will have to re-worked again. However since there 
doesn't seem to be any activity on DERBY-2109 I may just go ahead 
anyway.


Dan.
Please do not do this, at least not in a way which will make it 
necessary to rework and retest DERBY-2109.


I'll avoid doing this, I think there is a temp workaround I can do. If 
we get to the branch cutoff though without any progress on DERBY-2109 
then changes may need to be made.

Thanks, Dan.


Martin is actively working on this feature and deserves our patience 
and respect.


That's great, but you have to look at it from the issue of activity on 
the list: Given no messages for over two weeks from any contributor 
there are a number of scenarios one can imagine from not being active 
on derby anymore to being stuck on a problem that the community could 
possibly help with. Without communication it's impossible to tell so 
one has to assume not active if one wants to fry a fish in the same or 
overlapping area.



Each rework/retest cycle is turning out to be very expensive.


Is there a way the community could help, posting a newer version of 
the patch, helping solve issues, running the tests on various platforms?

It looks as though Martin has posted a comment on DERBY-2109.


I think this patch would have benefited from continuing the 
incremental development approach it started with. The current patch is 
trying to solve at least four issues. With an incremental approach my 
opinion is that most of the current patch's functionality could have 
already been committed, allowing focus on specific problems and a 
quicker turn-around on testing etc. I wonder if some folks are 
reluctant to perform incremental development because they think 
patches are too slow to be applied, thus they do a mega-patch which of 
course will take time to commit, thus we have a self-fulfilling prophecy?


Dan.

[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function

2008-02-27 Thread Thomas Nielsen (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573083#action_12573083
 ] 

Thomas Nielsen commented on DERBY-2998:
---

I've started looking at why the last two queries fail, and they both run down a 
code path I haven't been down before - involving a couple of JoinNodes and some 
trickery with the RCL. The predicate t1.a is pulled into the RCL, like we do 
for PRNs under certain conditions with a where predicate, and this somehow 
cause problems during code generation. I'll investigate more tomorrow, but as 
of now it doesn't look like its yet another RCL-WindowFunction assumption gone 
bad. It's probably related though - if I exchange the WindowFunction for a 
constant it works fine.

 Add support for ROW_NUMBER() window function
 

 Key: DERBY-2998
 URL: https://issues.apache.org/jira/browse/DERBY-2998
 Project: Derby
  Issue Type: Sub-task
  Components: SQL
Reporter: Thomas Nielsen
Assignee: Thomas Nielsen
Priority: Minor
 Attachments: d2998-10.diff, d2998-10.stat, d2998-11.diff, 
 d2998-12.diff, d2998-12.stat, d2998-13.diff, d2998-13.stat, d2998-14.diff, 
 d2998-14.stat, d2998-15.diff, d2998-15.stat, d2998-16.diff, d2998-16.stat, 
 d2998-17.diff, d2998-17.stat, d2998-18.diff, d2998-18.stat, d2998-4.diff, 
 d2998-4.stat, d2998-5.diff, d2998-5.stat, d2998-6.diff, d2998-6.stat, 
 d2998-7.diff, d2998-7.stat, d2998-8.diff, d2998-8.stat, d2998-9-derby.log, 
 d2998-9.diff, d2998-9.stat, d2998-doc-1.diff, d2998-doc-1.stat, 
 d2998-test.diff, d2998-test.stat, d2998-test2.diff, d2998-test2.stat, 
 d2998-test3.diff, d2998-test3.stat, d2998-test4.diff, d2998-test4.stat, 
 d2998-test6.diff, d2998-test7.diff, d2998-test8.diff


 As part of implementing the overall OLAP Operations features of SQL 
 (DERBY-581), implement the ROW_NUMBER() window function.
 More information about this feature is available at 
 http://wiki.apache.org/db-derby/OLAPRowNumber

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

[jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns


[ 
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573084#action_12573084
 ] 

Daniel John Debrunner commented on DERBY-3330:
--

I think the upgrade handling of IndexDescriptorImpl is too complex.

IndexDescriptorImpl uses a FormatableHashtable to store some of its state, the 
format of this can handle additional or missing keys. Thus the additional 
boolean required by this change can simply be added to the hash table, so the 
writeExternal has an additional:

 fh.putBoolean (isUniqueWhenNotNull, isUniqueWhenNotNull);

and the readExternal can have:

   if (fh.containsKey(isUniqueWhenNotNull)
   isUniqueWhenNotNull = fh.getBoolean(isUniqueWhenNotNull);
   else
   isUniqueWhenNotNull = ?? ; // what ever is the correct value for old 
indexes.

Of course good to comment the real code with when  why these changes were made.

 provide support for unique constraint over nullable columns
 ---

 Key: DERBY-3330
 URL: https://issues.apache.org/jira/browse/DERBY-3330
 Project: Derby
  Issue Type: New Feature
  Components: Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: BTreeController.diff, derby-3330-testcase.diff, 
 derby-3330.diff, derby-3330v10.diff, derby-3330v2.diff, derby-3330v3.diff, 
 derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, 
 derby-3330v8.diff, derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html, 
 FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html, 
 UniqueConstraint_Implementation_V2.html, 
 UniqueConstraint_Implementation_V3.html


 Allow unique constraint over nullable field. Right now derby support unique 
 constraint only over not null columns.

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

[jira] Updated: (DERBY-3330) provide support for unique constraint over nullable columns

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

Anurag Shekhar updated DERBY-3330:
--

Attachment: derby-3330v10.diff

Changes in this (derby-3330v10.diff) patch since (derby-3330v9.diff)

Modified java/engine/org/apache/derby/impl/sql/compile/TableElementList.java to
introduce a new method to check if any of the column in the constraint
definition can have null value. This method is used while creating backing
index for unique constraint and if all columns are non null able a backing
unique index is created. If any of the column are null able a non unique index
with uniqueWhenNotNull set to true.

nist script dml019.out doesn't requires any change now.

I haven't finished running tests on this patch.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
Issue Type: New Feature
Components: Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330-testcase.diff,
derby-3330.diff, derby-3330v10.diff, derby-3330v2.diff, derby-3330v3.diff,
derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff,
derby-3330v8.diff, derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html,
FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html,
UniqueConstraint_Implementation_V2.html,
UniqueConstraint_Implementation_V3.html

Allow unique constraint over nullable field. Right now derby support unique
constraint only over not null columns.

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

[jira] Commented: (DERBY-2109) System privileges

2008-02-27 Thread Rick Hillegas (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573086#action_12573086
 ] 

Rick Hillegas commented on DERBY-2109:
--

I'm waiting for the next rev of the patch before I start running unit tests. If 
the tests pass, I'm inclined to check this in in order to get the Replication 
and JMX folks unstuck. I'm hoping that we can treat the J2ME issue like the 
other issues: address it in a follow-on patch. Perhaps Martin could boost the 
priority of the J2ME issue. If we have to back this work out, on the branch, 
that's fine. However, I hope that our release manager will be willing to delay 
the release a bit if it looks like a little more effort could fix these 
outstanding issues.

 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

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

[jira] Created: (DERBY-3478) Simple column names specified as part of AS clause in a table expression are ignore if the table expression is a view.

Simple column names specified as part of AS clause in a table expression are 
ignore if the table expression is a view.


 Key: DERBY-3478
 URL: https://issues.apache.org/jira/browse/DERBY-3478
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.2.1, 10.3.1.4, 10.2.2.0, 10.2.1.6, 10.1.3.1, 
10.1.2.1, 10.1.1.0, 10.0.2.1
Reporter: A B
Priority: Minor


Simple repro as follows:

create table t1 (i int, j int);
insert into t1 values (1, 1), (1, -1), (2, 2), (3, -3), (4, 4);

create view v1 as select j, i from t1;
create view v2 (x,y,z) as select j, i, i+j from t1;

-- OK: Returns column names specified in AS clause.
select * from t1 as x(a,b);

-- OK: Returns column names for the views
select * from v1;
select * from v2;

-- WRONG: Ignores column names specified in AS clause for the views.
select * from v1 x(a,b);
select * from v2 as x(a,b,c);

I observed this as far back as 10.0.2.1, so this is not a regression.

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

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573096#action_12573096
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

The trouble is that the patch will break J2ME, all the other issues are related 
to this specific new code and do not have such a huge effect.

Would we commit a patch that broke Java SE 6?

 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

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

[jira] Updated: (DERBY-3448) Allow the MailJdbc system test to run under junit.

2008-02-27 Thread Manjula Kutty (JIRA)


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

Manjula Kutty updated DERBY-3448:
-

Attachment: DERBY-3448_diff_02_27.txt

Thanks for the suggestions Dan. Please review the updated patch. 

 Allow the MailJdbc system test to run under junit.
 --

 Key: DERBY-3448
 URL: https://issues.apache.org/jira/browse/DERBY-3448
 Project: Derby
  Issue Type: Improvement
  Components: Test
Reporter: Daniel John Debrunner
Assignee: Manjula Kutty
Priority: Minor
 Attachments: DERBY-3448_diff.txt_02_26_ver2.txt, 
 DERBY-3448_diff_02_26.txt, DERBY-3448_diff_02_27.txt, 
 DERBY-3448_stat_02_26.txt, derby_3448_dbtasks_cleanup.txt


 It would be good to get the mailjdbc test to run under junit to allow use of 
 the utilities there and decorators such as running the test getting all 
 connections from a data source with a statement caching.
 Could still allow the test to run standalone in its current form

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

Re: [jira] Commented: (DERBY-2109) System privileges

2008-02-27 Thread Myrna van Lunteren

On 2/27/08, Rick Hillegas (JIRA) [EMAIL PROTECTED] wrote:

[ 
 https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573086#action_12573086
  ]

 Rick Hillegas commented on DERBY-2109:
 --

 I'm waiting for the next rev of the patch before I start running unit tests. 
 If the tests pass, I'm inclined to check this in in order to get the 
 Replication and JMX folks unstuck. I'm hoping that we can treat the J2ME 
 issue like the other issues: address it in a follow-on patch. Perhaps Martin 
 could boost the priority of the J2ME issue. If we have to back this work out, 
 on the branch, that's fine. However, I hope that our release manager will be 
 willing to delay the release a bit if it looks like a little more effort 
 could fix these outstanding issues.

I am willing to apply the patch, run with J2ME and give feedback.
Please don't commit until I have a chance to do this - if this would
give lots of errors for J2ME it would certainly make my nightly tests
hard to deal with...
And I don't think it would be the right thing to do.

Myrna

[jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns

2008-02-27 Thread Dibyendu Majumdar (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573108#action_12573108
]

Dibyendu Majumdar commented on DERBY-3330:
--

Hi,

I could be talking nonsense here so please tell me to shut up if I have got the
wrong end of the issue.

If I understand correctly, one of the requirements is to allow multiple rows to
be inserted where the index is unique and all columns are null. This doesn't
work currently because such rows will be considered duplicates.

Thinking very naively, I would implement this as follows:

I am assuming that when index rows are stored, Derby always stores an
additional column containing the row location, regardless of the type of index.
Also that the search algorithm is uniform for both unique and non-unique
indexes, with the only difference being that the unique index searches do not
consider the extra row location column.
Following is invalid if above assumptions are not true.

To get the desired behaviour, I would simply change the comparison logic as
follows:

a) If non-unique index, no change.
b) If unique index, and all indexable columns are null, then compare the extra
(last) (row location) column.
c) The else case for unique index will remain the same as now.

If the key comparison routine always used above logic, would it not give
desired behaviour without requiring any significant changes to the existing
implementation?

As I said, I may totally off track here, so please feel free to tell me to shut
up.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
Issue Type: New Feature
Components: Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330-testcase.diff,
derby-3330.diff, derby-3330v10.diff, derby-3330v2.diff, derby-3330v3.diff,
derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff,
derby-3330v8.diff, derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html,
FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html,
UniqueConstraint_Implementation_V2.html,
UniqueConstraint_Implementation_V3.html

Allow unique constraint over nullable field. Right now derby support unique
constraint only over not null columns.

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

[jira] Commented: (DERBY-2109) System privileges

2008-02-27 Thread Rick Hillegas (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573110#action_12573110
 ] 

Rick Hillegas commented on DERBY-2109:
--

I would allow a patch which didn't work on Java 6 if it got other people 
unstuck and if I trusted the developer to submit a fix soon.

 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

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

[jira] Updated: (DERBY-3330) provide support for unique constraint over nullable columns


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

Mike Matrigali updated DERBY-3330:
--

Attachment: derbyall_report.txt

report of diffs on ibm15 jvm running on xp laptop using version 9 patch.

 provide support for unique constraint over nullable columns
 ---

 Key: DERBY-3330
 URL: https://issues.apache.org/jira/browse/DERBY-3330
 Project: Derby
  Issue Type: New Feature
  Components: Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: BTreeController.diff, derby-3330-testcase.diff, 
 derby-3330.diff, derby-3330v10.diff, derby-3330v2.diff, derby-3330v3.diff, 
 derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, 
 derby-3330v8.diff, derby-3330v9.diff, derbyall_report.txt, 
 FunctionalSpec_DERBY-3330-V2.html, FunctionalSpec_DERBY-3330.html, 
 UniqueConstraint_Implementation.html, 
 UniqueConstraint_Implementation_V2.html, 
 UniqueConstraint_Implementation_V3.html


 Allow unique constraint over nullable field. Right now derby support unique 
 constraint only over not null columns.

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

[jira] Updated: (DERBY-3330) provide support for unique constraint over nullable columns


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

Mike Matrigali updated DERBY-3330:
--


From running the v9 patch on ibm15 jvm against a windows XP laptop I got 1 
failure in the junit tests and 6 failures in the old style tests - i will 
attach a copy of the results for the old style test failures.  Are all tests 
passing in your environment with this patch?   I will try to run another set 
of tests over night with your latest patch - but do post what environment you 
are running the tests on and if they all pass or not with the v10 patch.

junit failure:
There was 1 failure:
1) dml019(org.apache.derbyTesting.functionTests.tests.nist.NistScripts)junit.fra
mework.ComparisonFailure: Output at line 85 expected:...1 |4... but was:...2
|8...
at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(Can
onTestCase.java:100)
at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptT
estCase.java:124)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

The following tests failed, will attach complete diff:
derbyall/derbyall.fail:lang/altertable.sql
derbyall/derbyall.fail:lang/db2Compatibility.sql
derbyall/derbyall.fail:lang/subqueryFlattening.sql
derbyall/derbyall.fail:tools/dblook_test.java
derbyall/derbynetclientmats/derbynetmats.fail:derbynet/dblook_test_net.java
derbyall/storeall/storeall.fail:store/rollForwardRecovery.sql

 provide support for unique constraint over nullable columns
 ---

 Key: DERBY-3330
 URL: https://issues.apache.org/jira/browse/DERBY-3330
 Project: Derby
  Issue Type: New Feature
  Components: Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: BTreeController.diff, derby-3330-testcase.diff, 
 derby-3330.diff, derby-3330v10.diff, derby-3330v2.diff, derby-3330v3.diff, 
 derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, 
 derby-3330v8.diff, derby-3330v9.diff, derbyall_report.txt, 
 FunctionalSpec_DERBY-3330-V2.html, FunctionalSpec_DERBY-3330.html, 
 UniqueConstraint_Implementation.html, 
 UniqueConstraint_Implementation_V2.html, 
 UniqueConstraint_Implementation_V3.html


 Allow unique constraint over nullable field. Right now derby support unique 
 constraint only over not null columns.

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

Re: [jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns

see discussion in DERBY-2212 for various issues related to this project
that led to the current design.

Dibyendu Majumdar (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573108#action_12573108 ]

Dibyendu Majumdar commented on DERBY-3330:
--

Hi,

I could be talking nonsense here so please tell me to shut up if I have got the wrong end of the issue.

Thinking very naively, I would implement this as follows:

To get the desired behaviour, I would simply change the comparison logic as
follows:

If the key comparison routine always used above logic, would it not give
desired behaviour without requiring any significant changes to the existing
implementation?

As I said, I may totally off track here, so please feel free to tell me to shut
up.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
Issue Type: New Feature
Components: Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330-testcase.diff,
derby-3330.diff, derby-3330v10.diff, derby-3330v2.diff, derby-3330v3.diff,
derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff,
derby-3330v8.diff, derby-3330v9.diff, FunctionalSpec_DERBY-3330-V2.html,
FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html,
UniqueConstraint_Implementation_V2.html, UniqueConstraint_Implementation_V3.html

Allow unique constraint over nullable field. Right now derby support unique
constraint only over not null columns.

Re: [jira] Commented: (DERBY-2109) System privileges


Rick Hillegas (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573110#action_12573110 ] 


Rick Hillegas commented on DERBY-2109:
--

I would allow a patch which didn't work on Java 6 if it got other people 
unstuck and if I trusted the developer to submit a fix soon.

I don't know the extent of the j2me issue, but it does not seem like a 
good idea to allow a patch that knowingly will break the entire system 
on a specific JVM.  I would not submit a patch that caused all tests to 
fail on a JAVA 6 jvm run, this could basically make it impossible for 
some community members to develop in their current environment until it

was addressed.  I would be ok for the sake of concurrent development to
check in a patch which had the functionality somehow disabled so that 
multiple people could enable it in their environment to make it work 
while not forcing others to suffer.   I do understand that it is a pain 
to joint develop in patches rather than in the svn source system. 
Again I don't how easy this would be in this case.



System privileges
-

Key: DERBY-2109
URL: https://issues.apache.org/jira/browse/DERBY-2109
Project: Derby
 Issue Type: New Feature
 Components: Security
   Affects Versions: 10.3.1.4
   Reporter: Rick Hillegas
   Assignee: Martin Zaun
Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
systemPrivs.html, systemPrivs.html


Add mechanisms for controlling system-level privileges in Derby. See the 
related email discussion at 
http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  secure 
in a client/server configuration. I'd like to plug more client/server security 
holes in 10.3. In particular, I'd like to focus on  authorization issues which 
the ANSI spec doesn't address.
Here are the important issues which came out of the email discussion.
Missing privileges that are above the level of a single database:
- Create Database
- Shutdown all databases
- Shutdown System
Missing privileges specific to a particular database:
- Shutdown that Database
- Encrypt that database
- Upgrade database
- Create (in that Database) Java Plugins (currently  Functions/Procedures, but 
someday Aggregates and VTIs)
Note that 10.2 gave us GRANT/REVOKE control over the following  
database-specific issues, via granting execute privilege to system  procedures:
Jar Handling
Backup Routines
Admin Routines
Import/Export
Property Handling
Check Table
In addition, since 10.0, the privilege of connecting to a database has been 
controlled by two properties (derby.database.fullAccessUsers and 
derby.database.defaultConnectionMode) as described in the security section of 
the Developer's Guide (see 
http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

Re: [jira] Commented: (DERBY-2109) System privileges

2008-02-27 Thread Kathey Marsden


Mike Matrigali wrote:




I don't know the extent of the j2me issue, but it does not seem like a 
good idea to allow a patch that knowingly will break the entire system 
on a specific JVM.  


+1
I think a patch that broke all tests with a certain JVM would disable 
our ability to detect regressions, and leave the project in a precarious 
state.  I would veto such a patch.


Kathey

Re: [jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns

2008-02-27 Thread Dibyendu Majumdar


Hi Mike,

I did go through DERBY-2212 - but did not think it had the same  
proposal.
However, you may be referring to the concerns you have with using  
unique index to store duplicate values.
Does the recovery code use a different comparison routine compared to  
the normal case?


I don't want to open up an older debate unnecessarily - so apologies  
if what I have proposed has been considered and discarded. Just that  
the current solution seems pretty complex ...


Regards

Dibyendu

On 28 Feb 2008, at 00:59, Mike Matrigali wrote:

see discussion in DERBY-2212 for various issues related to this  
project that led to the current design.


Dibyendu Majumdar (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3330? 
page=com.atlassian.jira.plugin.system.issuetabpanels:comment- 
tabpanelfocusedCommentId=12573108#action_12573108 ] Dibyendu  
Majumdar commented on DERBY-3330:

--
Hi,
I could be talking nonsense here so please tell me to shut up if I  
have got the wrong end of the issue. If I understand correctly,  
one of the requirements is to allow multiple rows to be inserted  
where the index is unique and all columns are null. This doesn't  
work currently because such rows will be considered duplicates.

Thinking very naively, I would implement this as follows:
I am assuming that when index rows are stored, Derby always stores  
an additional column containing the row location, regardless of  
the type of index.
Also that the search algorithm is uniform for both unique and non- 
unique indexes, with the only difference being that the unique  
index searches do not consider the extra row location column.

Following is invalid if above assumptions are not true.
To get the desired behaviour, I would simply change the comparison  
logic as follows:

a) If non-unique index, no change.
b) If unique index, and all indexable columns are null, then  
compare the extra (last)  (row location) column.

c) The else case for unique index will remain the same as now.
If the key comparison routine always used above logic, would it  
not give desired behaviour without requiring any significant  
changes to the existing implementation?
As I said, I may totally off track here, so please feel free to  
tell me to shut up.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/ 
DERBY-3330

Project: Derby
 Issue Type: New Feature
 Components: Store
   Affects Versions: 10.4.0.0
Environment: all
   Reporter: Anurag Shekhar
   Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330- 
testcase.diff, derby-3330.diff, derby-3330v10.diff,  
derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff,  
derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff,  
derby-3330v8.diff, derby-3330v9.diff, FunctionalSpec_DERBY-3330- 
V2.html, FunctionalSpec_DERBY-3330.html,  
UniqueConstraint_Implementation.html,  
UniqueConstraint_Implementation_V2.html,  
UniqueConstraint_Implementation_V3.html



Allow unique constraint over nullable field. Right now derby  
support unique constraint only over not null columns.

[jira] Updated: (DERBY-3461) EmbedSQLWarning should be renamed SQLWarningFactory and return java.sql.SQLWarning objects and not a Derby specific implementation.

2008-02-27 Thread Dibyendu Majumdar (JIRA)


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

Dibyendu Majumdar updated DERBY-3461:
-

Derby Info: [Patch Available]

Junit test cases have passed, except for the demo tests which for some reason 
fails on Mac OS X, using Java 1.5. Same error as reported in DERBY-3451.
I also ran derbyall on CentOS 5.1 using Java 1.6. 250 tests were run, with 1 
failure. The failure is in derbyall/derbylang/closed. It seems that the 
following line (appears twice) was unexpected:
Caused by: java.sql.SQLException: Database 'wombat' shutdown.
The failures do not seem to be related to the changes made in this patch.

 EmbedSQLWarning should be renamed SQLWarningFactory and return 
 java.sql.SQLWarning objects and not a Derby specific implementation.
 ---

 Key: DERBY-3461
 URL: https://issues.apache.org/jira/browse/DERBY-3461
 Project: Derby
  Issue Type: Improvement
  Components: JDBC, Services
Reporter: Daniel John Debrunner
Assignee: Dibyendu Majumdar
Priority: Minor
 Attachments: DERBY-3461_patch_1_r631372.txt


 One side effect is that the toString() of such a warning would change format 
 from starting with SQLWarning:  to java.sql.SQLWarning: , which should 
 match any warnings created on the network client side.
 See comments in DERBY-3453 as well for possible correct package of 
 SQLWarningFactory.
 Note: generateCsSQLWarning() can be removed as it doesn't seem to be used.
 Note: Also SQLWarningFactory would not extend java.sql.SQLWarning.

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

[jira] Updated: (DERBY-3358) After an incorrect(unsuccesfull) startMaster comand, further correct startMaster attempts also fail.


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

V.Narayanan updated DERBY-3358:
---

Attachment: Derby3358_v2.stat
Derby3358_v2.diff

In the attached patch I have addressed all the comments except
the following

d. startMaster(): Why not merge the to tests that give
REPLICATION_MODE_NOT_SUPPORTED in the same if statement? 

I have moved this test to canSupport as suggested. So I did not
need to do this change.

I added the comments to the boot method, but am not sure
if it matches your expectation. If it does not pls do mention and
I shall submit a new patch.

I have not changed the comments to active in startMaster, stopMaster and
startFailover. Here again I am not sure about the nature of the modification
you expected me to do. I request for more help from you here on the
style of the comments that would be expected. I shall submit a new
patch with the suggested modification.

 After an incorrect(unsuccesfull) startMaster comand, further correct 
 startMaster attempts also fail.
 

 Key: DERBY-3358
 URL: https://issues.apache.org/jira/browse/DERBY-3358
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b
Reporter: Ole Solberg
Assignee: V.Narayanan
 Attachments: Derby3358.diff, Derby3358.stat, Derby3358_v2.diff, 
 Derby3358_v2.stat


 Slave and master servers started.
 startSlave:
 CONNECT 
 'jdbc:derby://atum11:/test;startSlave=true;slaveHost=atum11;slavePort=8989';
 ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC: 
 Replication slave mode started successfully for database 'test'. Connection 
 refused because the database is in replication slave mode. 
 startMaster without specifying slavePort - will use default?
 CONNECT 'jdbc:derby://atum11:/test;startMaster=true;slaveHost=atum11';
 ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC: 
 nullXRE04
 master derby.log:
 2008-01-29 10:02:53.097 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance c013800d-0117-c4fb-9156-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/master/test  
 Database Class Loader started - derby.database.classpath=''
 2008-01-29 10:02:53.256 GMT Thread[DRDAConnThread_2,5,main] (XID = 419), 
 (SESSIONID = 0), (DATABASE = test), (DRDAID = {1}), Cleanup action starting
 java.sql.SQLException: Could not establish a connection to the peer of the 
 replicated database 'null'.
 .
 .
 Cleanup action completed
 2008-01-29 10:02:53.260 GMT Thread[DRDAConnThread_2,5,main] (DATABASE = 
 test), (DRDAID = {1}), Could not establish a connection to the peer of the 
 replicated database 'null'.
 startMaster specyfying slavePort:
 CONNECT 
 'jdbc:derby://atum11:/test;startMaster=true;slaveHost=atum11;slavePort=8989';
 ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC: 
 nullXRE04
 master derby.log:
 2008-01-29 10:03:38.201 GMT Thread[DRDAConnThread_2,5,main] (XID = 420), 
 (SESSIONID = 1), (DATABASE = test), (DRDAID = {2}), Cleanup action starting
 java.sql.SQLException: Could not establish a connection to the peer of the 
 replicated database 'null'.
 .
 .
 Cleanup action completed
 2008-01-29 10:03:38.205 GMT Thread[DRDAConnThread_2,5,main] (DATABASE = 
 test), (DRDAID = {2}), Could not establish a connection to the peer of the 
 replicated database 'null'.
 Additional observation/comment:
 
 It would be helpful for debugging if slaveHost and slavePort were written in 
 error messages and into derby.log.

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

[jira] Commented: (DERBY-3358) After an incorrect(unsuccesfull) startMaster comand, further correct startMaster attempts also fail.


[ 
https://issues.apache.org/jira/browse/DERBY-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573145#action_12573145
 ] 

V.Narayanan commented on DERBY-3358:


Thanks, for your patch Narayanan. I tried testing the patch, but the
bug reported in DERBY-3454 seems to get in the way.

You are correct. Every wrong connection attempt keeps throwing a
NPE. But when the correct port is mentioned the connection succeeds.
If the earlier bug, reported in this patch, had existed it would not have
succeeded, but would have continued with the NPE's.

 After an incorrect(unsuccesfull) startMaster comand, further correct 
 startMaster attempts also fail.
 

 Key: DERBY-3358
 URL: https://issues.apache.org/jira/browse/DERBY-3358
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b
Reporter: Ole Solberg
Assignee: V.Narayanan
 Attachments: Derby3358.diff, Derby3358.stat, Derby3358_v2.diff, 
 Derby3358_v2.stat


 Slave and master servers started.
 startSlave:
 CONNECT 
 'jdbc:derby://atum11:/test;startSlave=true;slaveHost=atum11;slavePort=8989';
 ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC: 
 Replication slave mode started successfully for database 'test'. Connection 
 refused because the database is in replication slave mode. 
 startMaster without specifying slavePort - will use default?
 CONNECT 'jdbc:derby://atum11:/test;startMaster=true;slaveHost=atum11';
 ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC: 
 nullXRE04
 master derby.log:
 2008-01-29 10:02:53.097 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance c013800d-0117-c4fb-9156-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/master/test  
 Database Class Loader started - derby.database.classpath=''
 2008-01-29 10:02:53.256 GMT Thread[DRDAConnThread_2,5,main] (XID = 419), 
 (SESSIONID = 0), (DATABASE = test), (DRDAID = {1}), Cleanup action starting
 java.sql.SQLException: Could not establish a connection to the peer of the 
 replicated database 'null'.
 .
 .
 Cleanup action completed
 2008-01-29 10:02:53.260 GMT Thread[DRDAConnThread_2,5,main] (DATABASE = 
 test), (DRDAID = {1}), Could not establish a connection to the peer of the 
 replicated database 'null'.
 startMaster specyfying slavePort:
 CONNECT 
 'jdbc:derby://atum11:/test;startMaster=true;slaveHost=atum11;slavePort=8989';
 ERROR XRE04: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC: 
 nullXRE04
 master derby.log:
 2008-01-29 10:03:38.201 GMT Thread[DRDAConnThread_2,5,main] (XID = 420), 
 (SESSIONID = 1), (DATABASE = test), (DRDAID = {2}), Cleanup action starting
 java.sql.SQLException: Could not establish a connection to the peer of the 
 replicated database 'null'.
 .
 .
 Cleanup action completed
 2008-01-29 10:03:38.205 GMT Thread[DRDAConnThread_2,5,main] (DATABASE = 
 test), (DRDAID = {2}), Could not establish a connection to the peer of the 
 replicated database 'null'.
 Additional observation/comment:
 
 It would be helpful for debugging if slaveHost and slavePort were written in 
 error messages and into derby.log.

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

[jira] Commented: (DERBY-3461) EmbedSQLWarning should be renamed SQLWarningFactory and return java.sql.SQLWarning objects and not a Derby specific implementation.


[ 
https://issues.apache.org/jira/browse/DERBY-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573148#action_12573148
 ] 

Daniel John Debrunner commented on DERBY-3461:
--

It's ok to leave the old versions of  the patch attached to the Jira issue, it 
allows reviewers to compare patches to get an idea of what changed between them.

What did change in the patch that fixed a test failure? I was expecting to see 
a master file (*.out) modified, but I didn't see one.

 EmbedSQLWarning should be renamed SQLWarningFactory and return 
 java.sql.SQLWarning objects and not a Derby specific implementation.
 ---

 Key: DERBY-3461
 URL: https://issues.apache.org/jira/browse/DERBY-3461
 Project: Derby
  Issue Type: Improvement
  Components: JDBC, Services
Reporter: Daniel John Debrunner
Assignee: Dibyendu Majumdar
Priority: Minor
 Attachments: DERBY-3461_patch_1_r631372.txt


 One side effect is that the toString() of such a warning would change format 
 from starting with SQLWarning:  to java.sql.SQLWarning: , which should 
 match any warnings created on the network client side.
 See comments in DERBY-3453 as well for possible correct package of 
 SQLWarningFactory.
 Note: generateCsSQLWarning() can be removed as it doesn't seem to be used.
 Note: Also SQLWarningFactory would not extend java.sql.SQLWarning.

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

[jira] Updated: (DERBY-3428) Doing a replication failover should shutdown the database and the connection should no longer be available


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

V.Narayanan updated DERBY-3428:
---

Attachment: Derby3428_v2.stat
Derby3428_v2.diff

The attached patch removes the dependency on 3455 

Pls find the repro run below

[EMAIL PROTECTED]:~/work/workspaces/Derby3428_v1/master$ java 
org.apache.derby.tools.ij
ij version 10.4
ij connect 'jdbc:derby:masterDB;user=oystein;password=pass;create=true';
ij call syscs_util.syscs_freeze_database();
0 rows inserted/updated/deleted
ij connect 
'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=8002';
ij(CONNECTION1) connect 
'jdbc:derby:masterDB;user=oystein;password=pass;failover=true'; 
ERROR XRE20: Failover performed successfully for database 'masterDB', the 
database has been shutdown.
ij(CONNECTION1) select * from sys.systables;
ERROR 08003: No current connection.
ij(CONNECTION1)

 Doing a replication failover should shutdown the database and the connection 
 should no longer be available
 --

 Key: DERBY-3428
 URL: https://issues.apache.org/jira/browse/DERBY-3428
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: Derby3428.diff, Derby3428.stat, Derby3428_v1.diff, 
 Derby3428_v1.stat, Derby3428_v2.diff, Derby3428_v2.stat


 Oystein says (as part of comments in Derby-3205)
 After executing a failover, I am told that the database is shut down, but I 
 still able to use the connection to access the database:
 ij version 10.4
 ij connect 'jdbc:derby:masterDB;user=oystein;password=pass';
 ij call syscs_util.syscs_freeze_database();
 0 rows inserted/updated/deleted
 ij connect 
 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost';
 ij(CONNECTION1) call syscs_util.syscs_unfreeze_database();
 0 rows inserted/updated/deleted
 ij(CONNECTION1) connect 
 'jdbc:derby:masterDB;user=oystein;password=pass;failover=true';
 ERROR XRE20: Failover performed successfully for database 'null', the 
 database has been shutdown.
 ij(CONNECTION1) select * from t;
 I
 ---
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 10
 11 rows selected
 ij(CONNECTION1)

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

[jira] Updated: (DERBY-3364) Replication failover implementation must be modified to fail at the master after slave has been stopped


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

V.Narayanan updated DERBY-3364:
---

Attachment: Derby3364_v4.stat
Derby3364_v4.diff

Moved tearDownNetwork to the finally block
of the stopMaster method.

 Replication failover implementation must be modified to fail at the master 
 after slave has been stopped
 ---

 Key: DERBY-3364
 URL: https://issues.apache.org/jira/browse/DERBY-3364
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: Derby3364_v1.diff, Derby3364_v1.stat, Derby3364_v2.diff, 
 Derby3364_v2.stat, Derby3364_v3.diff, Derby3364_v3.stat, Derby3364_v4.diff, 
 Derby3364_v4.stat


 Jorgen says...
 I tried to run the failover command on the master, which seems to work fine 
 as long as the master and slave are still connected. If the slave has been 
 stopped for some reason, however, failover hangs on 
 MasterController#startFailover here: 
 ack = transmitter.readMessage();

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

[jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns


[ 
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573151#action_12573151
 ] 

Daniel John Debrunner commented on DERBY-3330:
--

Dibyendu wrote:

 one of the requirements is to allow multiple rows to be inserted where the 
 index is unique and all columns are null.

but not the only requirement :-)

In a unique constraint these key columns are allowed:

   Smith, NULL
   Smith, NULL
   Smith, NULL

A unique index (from existing CREATE INDEX) would only allow one row with 
Smith,NULL


 

 provide support for unique constraint over nullable columns
 ---

 Key: DERBY-3330
 URL: https://issues.apache.org/jira/browse/DERBY-3330
 Project: Derby
  Issue Type: New Feature
  Components: Store
Affects Versions: 10.4.0.0
 Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
 Attachments: BTreeController.diff, derby-3330-testcase.diff, 
 derby-3330.diff, derby-3330v10.diff, derby-3330v2.diff, derby-3330v3.diff, 
 derby-3330v4.diff, derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, 
 derby-3330v8.diff, derby-3330v9.diff, derbyall_report.txt, 
 FunctionalSpec_DERBY-3330-V2.html, FunctionalSpec_DERBY-3330.html, 
 UniqueConstraint_Implementation.html, 
 UniqueConstraint_Implementation_V2.html, 
 UniqueConstraint_Implementation_V3.html


 Allow unique constraint over nullable field. Right now derby support unique 
 constraint only over not null columns.

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

Re: [jira] Commented: (DERBY-2109) System privileges

2008-02-27 Thread Daniel John Debrunner


Rick Hillegas (JIRA) wrote:


I would allow a patch which didn't work on Java 6 if it got other people unstuck

 and if I trusted the developer to submit a fix soon.

Apart from the issues of causing other folks grief as they need that 
platform working, one issue is that in an all volunteer development 
effort it's impossible to assume that anyone will follow up. We have had 
at least one patch where follow up work was promised but never happened. 
Stuff happens, people move on, if they are being paid to work on Derby 
their boss tells them to do something else.


Much better to always try to have the code in a working state.

Of course from time to time a patch will unexpectedly break a platform 
or a specific feature as it's not required that all tests are run on all 
possible platforms. Then someone just volunteers to fix it by some 
means, but in this case the J2ME issue was raised over a year ago.


Dan.

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573159#action_12573159
 ] 

Martin Zaun commented on DERBY-2109:



 Daniel John Debrunner wrote:
 1) Since J2ME/CDC/Foundation does not support some of the security classes 
 used, how is this being handled? Seems like it isn't at the moment. I think a 
 new abstract method is needed in InternalDriver called shutdownCheck() is 
 needed that would do nothing in J2ME but call the checks (through 
 SecurityUtil in J2SE.

The System Privileges checks are invoked from three places: 
NetworkServerControlImpl, InternalDriver, and EmbedConnection (and there may be 
more in future). They all call into SecurityUtil. Instead of introducing 
abstract methods in three different places, we may want to think about using 
SecurityUtil as a central switch for checking/not checking SystemPrivileges.

Right now SecurityUtil is is a static utility class, which doesn't support 
delegation.  I see the following options:
a) Make SecurityUtil an interface and (perhaps rename it) and have a public 
singleton class providing an instance appropriate to the environment (i.e., 
dummy implementation for J2ME).
b) Keep SecurityUtil as class but make its method non-static, abstract and 
introduce a static method getSecurityChecker() (or so) returning a singleton 
instance implementing these methods according to the environment.
c) Keep SecurityUtil as utility class but have the static methods internally 
delegate to an instance appropriate to the environment.

I like c) best since it keeps the callers unchanged.  Any thoughts/comments 
welcome.

If you have a pointer to a derby code example for me where switch 
implementation classes to accommodate J2ME, that would be helpful to me too.

Thanks,
Martin


 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, 
 DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

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

[jira] Updated: (DERBY-2109) System privileges