date:20080129

Replication slave got a fatal error for database 'test'. Replication will be
stopped. on insert on master db.
---

Key: DERBY-3356
URL: https://issues.apache.org/jira/browse/DERBY-3356
Project: Derby
Issue Type: Bug
Components: Replication
Affects Versions: 10.4.0.0
Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b
Reporter: Ole Solberg

1)
startSlave and startMaster done.
2)
Insert on master:
insert into t values
(200,'200'),(201,'201'),(202,'202'),(203,'203'),(204,'204');

Slave derby.log get:
BEGIN REPLICATION ERROR MESSAGE -
Replication slave got a fatal error for database 'test'. Replication will be
stopped.
ERROR XRE05: The log received from the master is not in synch with the local
log for replicated database 'test'. The received log instant is 4,295,058,963,
whereas the local instant is 4,294,986,347. This is FATAL for replication -
replication will be stopped.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:341)
at
org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.handleLogChunk(SlaveController.java:532)
at
org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:464)

- END REPLICATION ERROR MESSAGE --

Master derby.log: no change.

3)
stopMaster:
Master derby.log:
Replication master role stopped for database 'null'.

Slave derby.log: no change.
I.e. slave has not got stopSlave from master.

4)
Thus: Slave:
CONNECT 'jdbc:derby://atum11:/test';
ERROR 08004: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08004, SQLERRMC:
Connection refused to database 'test' because it is in replication slave mode.

Looks like after 2) master-slave communication is lost. But according to 4)
slave still thinks it has connection to master?

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

[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=12563424#action_12563424
]

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

Hi Narayanan,

I had a look at the failover_impl_3205_v1 patch, which looks good for the most
part. I have some comments - most of which are nits:

1) Indentation in EmbedConnection around line 340 is strange - do you use tab
length of four spaces? From the diff file I would guess you have a tab space of
8...
2) Typo in javadoc of EmbedConnection#isReplicationFailover - stopSlave
instead of failover.
3) AccessFactory - I think the new method failover would be easier to find if
it was placed close to the other replication methods. Feel free to ignore...
4) There are two Attribute.java files. I'm not sure if both are in use, but
previously replication attributes have been added to both files. We either need
some insight on which file can be ignored or continue to add the attributes to
both files.
5) RawStore.failover - Do you intend to write a follow-up patch with error
handling for the case that MasterFactory is not found by the Monitor?
6) The javadoc for failover in all the classes say StandardException is thrown
on error, but MasterController will always throw an exception. It would be
easier to understand the code if the javadoc described the reason for throwing
an exception even if failover was successful.
7) 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();
I'm not sure if this patch is the right one to fix this bug...

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: V.Narayanan
Attachments: derby-3205_startslave_dontcommit.diff,
derby-3205_startslave_dontcommit.stat,
failover_impl_3205_NotForCommit_v1.diff,
failover_impl_3205_NotForCommit_v1.stat, failover_impl_3205_v1.diff,
failover_impl_3205_v1.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

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] Assigned: (DERBY-3356) Replication slave got a fatal error for database 'test'. Replication will be stopped. on insert on master db.

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

Jørgen Løland reassigned DERBY-3356:

Assignee: Jørgen Løland

Replication slave got a fatal error for database 'test'. Replication will be
stopped. on insert on master db.
---

1)
startSlave and startMaster done.
2)
Insert on master:
insert into t values
(200,'200'),(201,'201'),(202,'202'),(203,'203'),(204,'204');
Slave derby.log get:
BEGIN REPLICATION ERROR MESSAGE -
Replication slave got a fatal error for database 'test'. Replication will be
stopped.
ERROR XRE05: The log received from the master is not in synch with the local
log for replicated database 'test'. The received log instant is
4,295,058,963, whereas the local instant is 4,294,986,347. This is FATAL for
replication - replication will be stopped.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:341)
at
org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.handleLogChunk(SlaveController.java:532)
at
org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:464)
- END REPLICATION ERROR MESSAGE --
Master derby.log: no change.
3)
stopMaster:
Master derby.log:
Replication master role stopped for database 'null'.
Slave derby.log: no change.
I.e. slave has not got stopSlave from master.
4)
Thus: Slave:
CONNECT 'jdbc:derby://atum11:/test';
ERROR 08004: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08004, SQLERRMC:
Connection refused to database 'test' because it is in replication slave mode.
Looks like after 2) master-slave communication is lost. But according to 4)
slave still thinks it has connection to master?

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

[jira] Updated: (DERBY-3357) Reduce runtime of jdbcapi.DataSourceTest


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

Kristian Waagan updated DERBY-3357:
---

Attachment: derby-3357-1a-lower_lock_timeout.diff

'derby-3357-1a-lower_lock_timeout.diff' lowers the lock timeout to 5 seconds 
for two of the tests.
Each test is run twice, and the fix reduced the runtime from 260 seconds to 40 
seconds on my machine.

Please comment if you believe this change is not acceptable, or that the lock 
timeout value must be set to another value.

 Reduce runtime of jdbcapi.DataSourceTest
 

 Key: DERBY-3357
 URL: https://issues.apache.org/jira/browse/DERBY-3357
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Trivial
 Fix For: 10.4.0.0

 Attachments: derby-3357-1a-lower_lock_timeout.diff


 Two tests in DataSoureTest are waiting for a lock timeout. The runtime of the 
 suite could be reduced by setting the lock timeout to a lower value.

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

[jira] Commented: (DERBY-3356) Replication slave got a fatal error for database 'test'. Replication will be stopped. on insert on master db.

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

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

Good catch Ole - we need to shut down the slave database when this happens.
That is, whenever the SlaveController gets a fatal exception, it needs to call
stopSlave

Replication slave got a fatal error for database 'test'. Replication will be
stopped. on insert on master db.
---

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

[jira] Created: (DERBY-3357) Reduce runtime of jdbcapi.DataSourceTest

Reduce runtime of jdbcapi.DataSourceTest


 Key: DERBY-3357
 URL: https://issues.apache.org/jira/browse/DERBY-3357
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Trivial
 Fix For: 10.4.0.0


Two tests in DataSoureTest are waiting for a lock timeout. The runtime of the 
suite could be reduced by setting the lock timeout to a lower value.

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

[jira] Updated: (DERBY-3324) JDBC statement cache implementation

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

Kristian Waagan updated DERBY-3324:
---

Attachment: derby-3324-1d-jdbc_statementcache.diff

'derby-3324-1d-jdbc_statementcache.diff' deprecates version 1c and contains
only two changes. I removed the redundant null check Knut Anders commented on
and fixed some bad formatting in the string created by StatementKey.toString.

JDBC statement cache implementation
---

Key: DERBY-3324
URL: https://issues.apache.org/jira/browse/DERBY-3324
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-3324-1a-jdbc_statementcache.diff,
derby-3324-1a-jdbc_statementcache.stat,
derby-3324-1b-jdbc_statementcache.diff,
derby-3324-1b-jdbc_statementcache.stat,
derby-3324-1c-jdbc_statementcache.diff,
derby-3324-1c-jdbc_statementcache.stat, derby-3324-1d-jdbc_statementcache.diff

Implement a cache for storing JDBC prepared statement objects.
The cache will be responsible for holding free prepared statement objects
that can be reused, and also to throw away objects if the cache grows too big.
All objects in the cache must belong to the same physical connection, but
they can be reused across logical connections obtained from a single physical
connection in a connection pool.
This component is probably a candidate for code sharing between the client
and the embedded driver. Sharing will not be part of this issue.

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

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

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
Affects Versions: 10.4.0.0
 Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b
Reporter: Ole Solberg


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] Created: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)

The log shipper needs to be modified to vary the shipping intervals dynamically 
(based on load)
---

 Key: DERBY-3359
 URL: https://issues.apache.org/jira/browse/DERBY-3359
 Project: Derby
  Issue Type: Sub-task
Reporter: V.Narayanan




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

[jira] Assigned: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)


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

V.Narayanan reassigned DERBY-3359:
--

Assignee: V.Narayanan

 The log shipper needs to be modified to vary the shipping intervals 
 dynamically (based on load)
 ---

 Key: DERBY-3359
 URL: https://issues.apache.org/jira/browse/DERBY-3359
 Project: Derby
  Issue Type: Sub-task
Reporter: V.Narayanan
Assignee: V.Narayanan



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

[jira] Commented: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)

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

V.Narayanan commented on DERBY-3359:

Keeping this in mind the following refined shipping scheme is proposed for the
first version of replication. If required the design can be later modified to
a more efficient and complex implementations in later refinements of
replication.

Basic Idea
--

The Log Buffer will notify the Log Shipper when a buffer is full. When the Log
Shipper gets this notification it will decide the action to be done the
following
way

1) It will retrieve the fill information from the Log Buffer. The fill
information
is a indicator of how full the log is at any point of time.

fill information = (full buffers/Total Buffers)*100

2) If the fill information is greater than 80 the log shipper will ship log
records
until the fill information returns a value less than 80. There will be no
time
delay between the ships.

3) If the fill information is less than 80 but greater than 10 the log shipper
will
ship with a MID ms delay. (*MID has not been decided yet*)

4) If the fill information is less than 10 the log shipper will ship with a MAX
ms delay
or when a buffer becomes full whichever comes first. The delay however will
not be
greater than MID.
(*MAX MID exact values of MAX has not been decided yet*).

Note: MID is a value that is only as large as not to affect the performance of
the master database
significantly.

max(MAX, DEFAULT_NUMBER_LOG_BUFFERS*MID) is the maximum delay between a
log record is committed at the master until
it is replicated to the slave. Maybe we should make sure that MAX
DEFAULT_NUMBER_LOG_BUFFERS*MID.

The log shipper needs to be modified to vary the shipping intervals
dynamically (based on load)
---

Key: DERBY-3359
URL: https://issues.apache.org/jira/browse/DERBY-3359
Project: Derby
Issue Type: Sub-task
Reporter: V.Narayanan
Assignee: V.Narayanan

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

2008-01-29 Thread Anurag Shekhar (JIRA)

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

Anurag Shekhar commented on DERBY-3330:
---

Thanks Mike for pointing out issues related to locking and also about the way
I have handled deleted row.

I went through the code you have have asked me to look for reference and also
the doIns code. This is what I think I should be doing.

Step 1. Find the slot where new row can be inserted.
Step 2. Get the left row (without checking for deleted row) if there is a match
try to
hold a lock. If lock is obtained without releasing the latch no other
transaction is
working on it and it should be a deleted row. return error if its not.
If latch was released tree has under gone some changes and start with step 1.

Step3. Repeat step 2 for right row.

I am checking out B2IRowLocking3.searchLeftAndLockPreviousKey and will be
posting about locking scheme and effect of isolation level shortly.

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: derby-3330-testcase.diff, derby-3330.diff,
derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff,
FunctionalSpec_DERBY-3330-V2.html, FunctionalSpec_DERBY-3330.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-2142) NullPointerException while using XAConnection/PooledConnection in a heavily contended multithreaded scenario


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

Kristian Waagan commented on DERBY-2142:


Thanks for adding the test fixture Dan.

I think the client driver might have the same problem as the embedded driver. 
I'm currently working in that area of the code, and I'll investigate it.
If required, I'd like to attach a patch to this issue.

 NullPointerException while using XAConnection/PooledConnection in a heavily 
 contended multithreaded scenario
 

 Key: DERBY-2142
 URL: https://issues.apache.org/jira/browse/DERBY-2142
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 
 10.2.1.6
 Environment: The issue can appear in any environment as the bug is in 
 the source code . The bug has been verified in Suse Linux env.
Reporter: Asif H. Shahid
Assignee: Kathey Marsden
 Attachments: derby-2142_diff.txt, derby-2142_diff2.txt, 
 derby-2142_diff3.txt, derby-2142_stat.txt


 We are using the Derby's Transactional DataSource  class ( 
 org.apache.derby.jdbc.EmbeddedXADataSource ) to create a pool of  
 XAConnections in our application.
 Whenever a thread in a JTA transaction requests for a SQLConnection , we 
 retrieve an XAConnection from the pool. From the XAConnection , we  register 
 the XAResource with the TransactionManager  return a java.sql.Connection to 
 the application. 
 A class implementing the ConnectionEventListener is registered with the 
 XAConnection to get callback  connectionClosed ( ) when the thead closes the 
 java.sql.Connection. In this callback,  we invoke XAResource.end  return the 
 XAConnection to our pool  so that other threads can use it.
 We have encountered NullPointerException  , when performing operation on 
 java.sql.Connection.
 The stacktrace is as follows
 at
 org.apache.derby.jdbc.XAStatementControl.init(XAStatementControl.java:71)
at
 org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:162)
at
 org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(Unknown
 Source)
at
 com.gemstone.gemfire.internal.datasource.ConnectionPoolingTest$1.run(ConnectionPoolingTest.java:174)
at java.lang.Thread.run(Thread.java:595)
 I have done some debugging on source code of  db-derby-10.2.1.6-src  have 
 following explanation of the bug  a suggested fix. However, I want to 
 confirm that it is genuinely a bug  not a problem in our understanding of 
 the Datasource spec behaviour.
 Reason for the bug:-
 The class EmbedPooledConnection.java   stores in the field 
 currentConnectionHandle ( of  class BrokeredConnection)  a reference of the 
 java.sql.Connection object , being returned to the application, 
 Now ,whenever the client closes the java.sql.Connection ,  the code flow is 
 EmbedPooledConnection.close() -- EmbedPooledConnection.notifyClose().
 In the function EmbedPooledConnection.notifyClose(), it notifies  my listener 
 ( javax.sql.ConnectionEventListener) ) where I return the XAConnection to the 
 pool ( after deregistering the XAResource). 
 The last line of EmbedPooledConnection.close()  makes the 
 currentConnectionHandle  field as null.
 The issue here is that  javax.sql.ConnectionEventListener.connectionClosed is 
 invoked before making the currentConenctionHandle field as null.  Thus 
 XAConnection is returned to the pool , ready for pickup by a new thread. This 
 new thread obtains a java.sql.Connection whose reference gets assigned to the 
 currentConnectionHandle field, meanwhile the previous thread completes the 
 EmbedPooledConnection.close  making the newly assigned 
 currentConnectionHandle as null.
 Thus a previous thread's close makes a field null of an XAConnection, which 
 has been assigned to a new thread.
 The bug is easily reproducible  in a multi threaded scenario ( 20 threads or 
 so) with a pool size of around 4 XAConnections so that there is heavy  
 contention on XAConnection. 
 The fix is to rearrange the code of EmbedPooledConenction.java 's 
 closingConnection () as
 bug :
 public  boolean closingConnection() {
  notifyClose();
  currentConnectionHandle = null;
 return false;
 }
 bug fix :
 public  boolean closingConnection() {
  currentConnectionHandle = null;
  notifyClose();
  return false;
 }

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

[jira] Commented: (DERBY-3347) ERROR XSDB3: Container information cannot change once written


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

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

Thanks for taking the time to run these experiments, Bogdan!

At least, now we know the problem is not caused by DERBY-3099 or DERBY-3116, 
and we know that it must have been introduced some time after 10.2.2.0 and 
before 10.3.1.4.

One thing I know was changed in that area of the code in that period, is that 
RAFContainer started using java.nio.* to allow parallel reads and writes on 
JVMs that support nio. It is possible to force the use of the old mechanism by 
deleting or commenting out the following lines in 
java/engine/org/apache/derby/modules.properties and rebuilding derby.jar:

# store data using a StorageFactory
# Enhanced version using NIO API; requires Java 1.4
derby.module.rawStore.data.genericJ4=org.apache.derby.impl.store.raw.data.BaseDataFileFactoryJ4
derby.env.jdk.rawStore.data.genericJ4=4
derby.env.classes.rawStore.data.genericJ4=java.nio.Buffer
cloudscape.config.rawStore.data.genericJ4=derby

It would be great if you could make that change and rerun your test.

 ERROR XSDB3: Container information cannot change once written
 -

 Key: DERBY-3347
 URL: https://issues.apache.org/jira/browse/DERBY-3347
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.2.1
 Environment: Windows 2003 Server
 Sun Java 1.6.0_03
Reporter: Bogdan Calmac
Priority: Critical

 We are using derby as an embedded DB for our data collection server. During 
 an endurance test when we do around 270 inserts and 9 updates per second, for 
 about a week, I ocasionally see the error below in the deby log (and nothing 
 else beside this).
 This is a vanilla installation, we run derby embedded with no extra 
 configuration.  I can confirm that there is no memory problem, the heap usage 
 seems constant over time.
 Can somebody provide some more information regarding the effects of this 
 error? By looking at the stacktrace, it looks like a checkpoint operation is 
 aborted due to some inconsistency in the internal data structure. If the 
 error does not repeat immediately, does it mean that the next checkpoint is 
 successful and there is no data loss? 
 I can't provide a test case for that, the error happens after about 1-2 day 
 of running our software. I will rerun the test with the debug jars to capture 
 the line numbers in the stacktrace.  Also, I'm starting another test with 
 10.2.2.0, to see if this problem was introduced in the latest version.
 There are another two bugs referring to this error, 
 (https://issues.apache.org/jira/browse/DERBY-2284 and 
 https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in 
 response to some client action. This use case is a bit different, the client 
 keeps inserting and updating records for several days in a steady manner and 
 at some point the error pops up.
 And lastly, here is the exception:
 Checkpoint Daemon caught standard exception
   BEGIN ERROR STACK -
 ERROR XSDB3: Container information cannot change once written: was 0, now 80
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source)
   at 
 org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown 
 Source)
   at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown 
 Source)
   at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source)
   at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source)
   at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source)
   at 
 org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown 
 Source)
   at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown 
 Source)
   at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source)
   at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown 
 Source)
   at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown 
 Source)
   at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source)
   at java.lang.Thread.run(Thread.java:619)
   END ERROR STACK -

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

[jira] Issue Comment Edited: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)

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

narayanan edited comment on DERBY-3359 at 1/29/08 2:24 AM:
-

Introduction

The log shipper currently has a static shipping interval of 1 second with
a forceFlush capability when the buffer becomes full. This algorithm does not
augur well in the real-time environment and the bond between the buffer fill
and the log shipper frequency needs to be strengthened to allow shipping
to depend on incoming transaction load.

Basic Idea
--

The Log Buffer will notify the Log Shipper when a buffer is full. When the Log
Shipper gets this notification it will decide the action to be done the
following
way

1) It will retrieve the fill information from the Log Buffer. The fill
information
is a indicator of how full the log is at any point of time.

fill information = (full buffers/Total Buffers)*100

2) If the fill information is greater than 80 the log shipper will ship log
records
until the fill information returns a value less than 80. There will be no
time
delay between the ships.

3) If the fill information is less than 80 but greater than 10 the log shipper
will
ship with a MID ms delay. (*MID has not been decided yet*)

Note: MID is a value that is only as large as not to affect the performance of
the master database
significantly.

was (Author: narayanan):
Keeping this in mind the following refined shipping scheme is proposed for
the
first version of replication. If required the design can be later modified to
a more efficient and complex implementations in later refinements of
replication.

Basic Idea
--

The Log Buffer will notify the Log Shipper when a buffer is full. When the Log
Shipper gets this notification it will decide the action to be done the
following
way

1) It will retrieve the fill information from the Log Buffer. The fill
information
is a indicator of how full the log is at any point of time.

fill information = (full buffers/Total Buffers)*100

2) If the fill information is greater than 80 the log shipper will ship log
records
until the fill information returns a value less than 80. There will be no
time
delay between the ships.

3) If the fill information is less than 80 but greater than 10 the log shipper
will
ship with a MID ms delay. (*MID has not been decided yet*)

Note: MID is a value that is only as large as not to affect the performance of
the master database
significantly.

The log shipper needs to be modified to vary the shipping intervals
dynamically (based on load)
---

Key: DERBY-3359
URL: https://issues.apache.org/jira/browse/DERBY-3359
Project: Derby
Issue Type: Sub-task
Reporter: V.Narayanan
Assignee: V.Narayanan

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

[jira] Commented: (DERBY-3361) Specifying a non-existant slaveHost for startSlave seemingly succeeds in starting slave mode.


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

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

Currently, any attempt of running startSlave that does not fail authorization 
will report that slave mode was started successfully. Before returning the 
successfully started message to the client, we need to verify that everything 
is well. This issue will handle the reported problem and any other reason for 
slave replication to fail starting.

Note that the reason for this problem is that when SlaveDatabase is booted, it 
kicks off a new thread that boots the store modules. Hence, any exception 
thrown as part of booting store is not currently propagated to the client.

 Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
 starting slave mode.
 -

 Key: DERBY-3361
 URL: https://issues.apache.org/jira/browse/DERBY-3361
 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: Jørgen Løland

 Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
 starting slave mode.
 ---
  CONNECT 
 'jdbc:derby://atum11:/test;startSlave=true;slaveHost=noSuchHost;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. 
 Slave derby.log shows a NPE:
 --
 2008-01-29 11:52:40.050 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance c013800d-0117-c563-d051-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/slave/test  
 Database Class Loader started - derby.database.classpath=''
 2008-01-29 11:52:40.308 GMT:
 Shutting down instance c013800d-0117-c563-d051-03bf6570
 
 
 2008-01-29 11:52:40.320 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance a816c00e-0117-c563-d051-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/slave/test  
 2008-01-29 11:52:40.814 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
 starting
 ERROR XRE08: Replication slave mode started successfully for database 'test'. 
 Connection refused because the database is in replication slave mode. 
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
   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:211)
   at 
 org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
   at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
 Cleanup action completed
 2008-01-29 11:52:40.816 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
 starting
 ERROR XRE08: Replication slave mode started successfully for database 'test'. 
 Connection refused because the database is in replication slave mode. 
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection30.init(EmbedConnection30.java:73)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection40.init(EmbedConnection40.java:54)
   at

[jira] Assigned: (DERBY-3361) Specifying a non-existant slaveHost for startSlave seemingly succeeds in starting slave mode.


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

Jørgen Løland reassigned DERBY-3361:


Assignee: Jørgen Løland

 Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
 starting slave mode.
 -

 Key: DERBY-3361
 URL: https://issues.apache.org/jira/browse/DERBY-3361
 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: Jørgen Løland

 Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
 starting slave mode.
 ---
  CONNECT 
 'jdbc:derby://atum11:/test;startSlave=true;slaveHost=noSuchHost;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. 
 Slave derby.log shows a NPE:
 --
 2008-01-29 11:52:40.050 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance c013800d-0117-c563-d051-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/slave/test  
 Database Class Loader started - derby.database.classpath=''
 2008-01-29 11:52:40.308 GMT:
 Shutting down instance c013800d-0117-c563-d051-03bf6570
 
 
 2008-01-29 11:52:40.320 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance a816c00e-0117-c563-d051-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/slave/test  
 2008-01-29 11:52:40.814 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
 starting
 ERROR XRE08: Replication slave mode started successfully for database 'test'. 
 Connection refused because the database is in replication slave mode. 
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
   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:211)
   at 
 org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
   at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
 Cleanup action completed
 2008-01-29 11:52:40.816 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
 starting
 ERROR XRE08: Replication slave mode started successfully for database 'test'. 
 Connection refused because the database is in replication slave mode. 
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
   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:211)
   at 
 org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
   at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
   at

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

2008-01-29 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-9-derby.log
d2998-9.stat
d2998-9.diff

Attaching minor updates according to Ricks comment in d2998-9.diff.

The query/executable plan is attached in d2998-9-derby.log, with d2998-9.diff 
applied, executing:
   select * from (select row_number() over () as r, t.* from t) as tr;

The 9 patch attached does not evaluate WHERE clauses on expression columns in 
the materialized subquery resultset correctly.

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


 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] Created: (DERBY-3361) Specifying a non-existant slaveHost for startSlave seemingly succeeds in starting slave mode.

Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
starting slave mode.
-

 Key: DERBY-3361
 URL: https://issues.apache.org/jira/browse/DERBY-3361
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
 Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b 
Reporter: Ole Solberg


Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
starting slave mode.
---

 CONNECT 
'jdbc:derby://atum11:/test;startSlave=true;slaveHost=noSuchHost;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. 



Slave derby.log shows a NPE:
--

2008-01-29 11:52:40.050 GMT:
 Booting Derby version The Apache Software Foundation - Apache Derby - 10.4.0.0 
alpha - (615841M): instance c013800d-0117-c563-d051-03bf6570
on database directory 
/export/home/tmp/os136789/Replication_common_Trunk/slave/test  

Database Class Loader started - derby.database.classpath=''

2008-01-29 11:52:40.308 GMT:
Shutting down instance c013800d-0117-c563-d051-03bf6570


2008-01-29 11:52:40.320 GMT:
 Booting Derby version The Apache Software Foundation - Apache Derby - 10.4.0.0 
alpha - (615841M): instance a816c00e-0117-c563-d051-03bf6570
on database directory 
/export/home/tmp/os136789/Replication_common_Trunk/slave/test  

2008-01-29 11:52:40.814 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
starting
ERROR XRE08: Replication slave mode started successfully for database 'test'. 
Connection refused because the database is in replication slave mode. 
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
at 
org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
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:211)
at 
org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
at 
org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
at 
org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090)
at 
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932)
at 
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
Cleanup action completed
2008-01-29 11:52:40.816 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
starting
ERROR XRE08: Replication slave mode started successfully for database 'test'. 
Connection refused because the database is in replication slave mode. 
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
at 
org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
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:211)
at 
org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
at 
org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
at 
org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090)
at 
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932)
at 
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
Cleanup action completed
2008-01-29 11:52:40.816

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

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.2
 Environment: Derby 10.3 Branch [10.3.2.2 - (616244M)]
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


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 = URID.h
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:115)
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.BinaryLogicalOperatorNode.generateExpression(BinaryLogicalOperatorNode.java:157)
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.JoinNode.getJoinArguments(JoinNode.java:1579)
at 
org.apache.derby.impl.sql.compile.JoinNode.generateCore(JoinNode.java:1555)
at 
org.apache.derby.impl.sql.compile.JoinNode.generate(JoinNode.java:1479)
at 
org.apache.derby.impl.sql.compile.JoinNode.getJoinArguments(JoinNode.java:1577)
at 
org.apache.derby.impl.sql.compile.JoinNode.generateCore(JoinNode.java:1555)
at 
org.apache.derby.impl.sql.compile.JoinNode.generate(JoinNode.java:1479)
at 
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1440)
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.EmbedPreparedStatement.init(EmbedPreparedStatement.java:129)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(EmbedPreparedStatement20.java:82)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(EmbedPreparedStatement30.java:63)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(EmbedPreparedStatement40.java:40)
at 
org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Driver40.java:105)
at 
org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:923)
at 
org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:751)

   [..]
at 
org.apache.derby.exe.ac12564092x0117xc525x43e4xbce342b018.g0(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46)
at

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-29 Thread Dyre Tjeldvoll (JIRA)


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

Dyre Tjeldvoll commented on DERBY-3301:
---

AB Dyre, if you're still looking to commit the changes for this issue,

Anyone should feel free to commit it :) But yes, I do think it is an important 
and complex fix which will benefit from being run in the nightly regression 
tests for a while before the next release. 
I have applied the patches successfully and I'm running the tests. I plan to 
commit them later this afternoon. 

On a related note; this is not a regression, but would it still make sense to 
merge it to 10.3. ?

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
Assignee: Thomas Nielsen
 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, 
 derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, 
 derby-3301-4c.diff, derby-3301-test-1.diff, derby-3301-test-1.stat, 
 derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, 
 derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY

[jira] Assigned: (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 reassigned DERBY-3358:
--

Assignee: V.Narayanan

 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

 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-3354) Select from large lob table with embedded gives OutOfMemoryError

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

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

I believe this is because EmbedConnection.addLobMapping is called for every
lob creation but is never cleared until commit or rollback, even if the lob
is freed.

I believe your analysis is correct. free() should remove the mapping.
Unfortunately, the lob doesn't know about its locator value, but it seems like
your about to change that by adding a getLocator() method in DERBY-3243.

On DERBY-3243 I wrote:
Another thing I came to think about: Would it be better to remove
addLOBMapping() from the constructors in EmbedBlob/EmbedClob and instead call
it lazily from getLocator()? (...) Then we'd also remove the overhead of
maintaining the lob mapping in embedded mode.

I think that change would fix the OOME (on embedded, but we'd probably still
see it in a client/server environment).

Now, it seems like DERBY-2787 added the call to addLOBMapping() intentionally
to ensure that free() was called on commit/rollback and temporary files would
be deleted. Moving addLOBMapping() out of the constructors would probably
reintroduce the problem with temporary files not being deleted. However, the
lobs only create temporary files when they are modified and the new size of the
lob is greater than the buffer in LOBStreamControl, so it shouldn't be
necessary to have commit/rollback call free() on all lobs to delete the
temporary files. It would probably be enough if each lob added itself to a list
in the connection each time a temporary file was created in
LOBStreamControl.init(). (addLOBMapping() is probably OK, but it feels a bit
strange to piggyback on a locator mechanism to do this cleanup when we don't
actually care about the locators.)

Select from large lob table with embedded gives OutOfMemoryError

Key: DERBY-3354
URL: https://issues.apache.org/jira/browse/DERBY-3354
Project: Derby
Issue Type: Bug
Components: SQL
Reporter: Kathey Marsden
Attachments: LocLeak.java

Retrieving from a large table with lobs gives an OutOfMemoryException, even
if free() is explictly called on the lob. I believe this is because
EmbedConnection.addLobMapping is called for every lob creation but is never
cleared until commit or rollback, even if the lob is freed.

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

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


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

northshorefiend edited comment on DERBY-3360 at 1/29/08 6:40 AM:
-

More info,

CAST(FN_MATCHES(..) AS INTEGER) avoids the bug.

10.3.1.4 (sane) shows this behaviour too



  was (Author: northshorefiend):
More info,

CAST(FN_MATCHES(..) AS INTEGER) avoids the bug.

10.3.2.1 and 10.3.1.4 do not show this behaviour
  
 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.2
 Environment: Derby 10.3 Branch [10.3.2.2 - (616244M)]
 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

 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 = URID.h
 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:115)
 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.BinaryLogicalOperatorNode.generateExpression(BinaryLogicalOperatorNode.java:157)
 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.JoinNode.getJoinArguments(JoinNode.java:1579)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generateCore(JoinNode.java:1555)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generate(JoinNode.java:1479)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.getJoinArguments(JoinNode.java:1577)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generateCore(JoinNode.java:1555)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generate(JoinNode.java:1479)
 at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1440)
 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.EmbedPreparedStatement.init(EmbedPreparedStatement.java:129)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(EmbedPreparedStatement20.java:82)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(EmbedPreparedStatement30.java:63)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(EmbedPreparedStatement40.java:40)
 at 
 org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Driver40.java:105)
 at 
 org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:923)
 at

[jira] Commented: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)


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

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

Thank you for the very clear description of the issue, Narayanan. This looks 
like a good idea to me. 

A question: How will MAX and MID be set? Do you intend for these to be 
hardcoded constants, properties that can be decided by the user or something 
else?

 The log shipper needs to be modified to vary the shipping intervals 
 dynamically (based on load)
 ---

 Key: DERBY-3359
 URL: https://issues.apache.org/jira/browse/DERBY-3359
 Project: Derby
  Issue Type: Sub-task
Reporter: V.Narayanan
Assignee: V.Narayanan



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

[jira] Updated: (DERBY-2683) tools and utilities guide: ij.URLCheck's list of checked attributes is not correct

2008-01-29 Thread Kim Haase (JIRA)


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

Kim Haase updated DERBY-2683:
-

Derby Info: [Patch Available]

 tools and utilities guide: ij.URLCheck's list of checked attributes is not 
 correct
 --

 Key: DERBY-2683
 URL: https://issues.apache.org/jira/browse/DERBY-2683
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.1.6, 10.2.2.0
Reporter: Dag H. Wanvik
Assignee: Kim Haase
Priority: Minor
 Attachments: DERBY-2683.diff, rtoolsijpropref38481.html


 The list contains the attribute 
unicode
 which is not supported. This attribute is also used in an example.
 Other attributes which are supported are not listed include
newBootPassword
encryptionKey
newEncryptionKey
createFrom
restoreFrom
rollForwardRecoveryFrom
securityMechanism
  

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

2008-01-29 Thread Henri . Vandescheur

[Auto-generated mail]

*Daily* 615952/2008-01-28 18:01:08 MET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
0273273 071.99% derbyall
01017010170 0   1415.96% suitesAll
 linN+1
0273273 0   103.61% derbyall
01017010170 0   115.53% suitesAll
 sles
1273272 073.07% derbyall
01017010170 0   869.44% suitesAll
 sol
0273273 076.61% derbyall
01017010170 0   1718.63% suitesAll
 solN+1
0273273 097.17% derbyall
01017010170 0   199.73% suitesAll
 sparc
0273273 065.74% derbyall
01017010170 0   359.95% suitesAll
 vista
0273273 093.36% derbyall
091489148 068.25% suitesAll
 w2003
0273273 095.84% derbyall
091489148 0   132.66% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-615952.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/615952_bySig.html 

*Jvm: 1.5*
 lin
0274274 071.88% derbyall
084528452 0   882.88% suitesAll
 linN+1
0274274 099.10% derbyall
084528452 0   116.63% suitesAll
 sles
0274274 070.42% derbyall
084528452 0   575.79% suitesAll
 sol
0274274 079.24% derbyall
084528452 0   836.74% suitesAll
 solN+1
0274274 088.55% derbyall
084528452 0   794.83% suitesAll
 sparc
0274274 066.67% derbyall
084528452 0   690.76% suitesAll
 vista
0274274 092.17% derbyall
074307430 0   485.17% suitesAll
 w2003
0274274 073.85% derbyall
074307430 0   259.45% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-615952.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/615952_bySig.html 

*Jvm: 1.4*
 lin
0271271 272.93% derbyall
084008400 0   792.29% suitesAll
 linN+1
0271271 299.69% derbyall
084008400 0   115.35% suitesAll
 sles
0271271 271.65% derbyall
084008400 0   525.27% suitesAll
 sol
0271271 278.02% derbyall
084008400 0   673.52% suitesAll
 solN+1
0271271 289.25% derbyall
084008400 0   748.92% suitesAll
 sparc
0271271 267.10% derbyall
084008400 0   697.68% suitesAll
 vista
1271270 2   102.49% derbyall
073787378 0   470.64% suitesAll
 w2003
0271271 275.21% derbyall
073797379 0   249.34% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-615952.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/615952_bySig.html 

---

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

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

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby


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

John H. Embretsen commented on DERBY-1387:
--

I should probably mention that I have run suites.All and derbyall successfully 
using jdk1.4 with (roughly) the -9 patch (I did some minor tweaking after 
testing but before submitting), so I'm fairly confident that it won't break 
existing code in an obvious way. Will run more tests later.

 Add JMX extensions to Derby
 ---

 Key: DERBY-1387
 URL: https://issues.apache.org/jira/browse/DERBY-1387
 Project: Derby
  Issue Type: New Feature
  Components: Services
Reporter: Sanket Sharma
Assignee: John H. Embretsen
 Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff, 
 DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff, 
 DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip, 
 DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat, 
 derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, Requirements for JMX 
 Updated.html, Requirements for JMX.html, Requirements for JMX.zip


 This is a draft requirement specification for adding monitoring and 
 management extensions to Apache Derby using JMX. The requirements document 
 has been uploaded on JIRA as well as the Derby Wiki page at 
 http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX
 Developers and Users are requested to please look at the document (feature 
 list in particular) and add their own rating to features by adding a coloumn 
 to the table.
 Comments are welcome.

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

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-29 Thread A B (JIRA)


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

A B commented on DERBY-3301:


 With the two patches I get a failure in lang/subqueryFlattening.sql. 

Good catch, Dyre.  I was operating on the assumption that derbyall ran cleanly 
with
the 4c patch; I hadn't run it myself.

 From a quick look at the diff it seems like the test dumps a query plan that 
 is different
 with the patch

I confirmed that there is one query for which the query plan is different--and 
for that specific query,
I think the difference is correct.  Namely, the query has nested WHERE EXISTS 
subqueries and so,
according to the findings for this issue, cannot be safely flattened.  So that 
part seems okay.

I then noticed that another query further down in the test _also_ has nested 
WHERE EXISTS
subqueries, but that query _is_ in fact flattened into an exists join--which 
runs counter to the
findings so far for this issue (i.e. it shouldn't be flattened into an EXISTS 
due to the nested
EXISTS subqueries).  The fact that the query in subqueryFlattening still 
returns correct rows
suggests that maybe there are cases where flattening of EXISTS subqueries is 
safe--but
that seems beyond the scope of this issue.

I played around with the repro for this issue and was able to write the 
following query:

select unbound_e.empid, unbound_p.projid
from departments this,
 employees unbound_e,
 projects unbound_p
where exists (
select 1 from employees this_employees_e
where 1 = 1 and exists (
select 1 from project_employees this_employees_e_projects_p
where this_employees_e_projects_p.empid = this_employees_e.empid
and this_employees_e.department = this.id
and unbound_p.projid = this_employees_e_projects_p.projid
and unbound_e.empid = this_employees_e.empid)
);

The only difference between this query and the one in derby-3301.sql is that 
I've
added a (no-op) predicate 1 = 1 alongside the inner-most EXISTS clause.
Since this creates an AndNode whose left operand is a relational op (1 = 1) 
and
whose right operand is a SubqueryNode, the code in the 4c patch that checks
specifically for a SubqueryNode will not detect it:

+   if (sn.originalWhereClause != null 
+   sn.originalWhereClause instanceof SubqueryNode)  {
+   ...

Since whereClause here is actually an AndNode, not a SubqueryNode, the if 
statement
above is not triggered, thus the query is incorrectly flattened into an EXISTS 
joins.  The
end result is that the query only returns 5 rows when it should return 7 (the 
extra 1 = 1
predicate shouldn't affect the results).

I think I mentioned a few comments ago that it might be possible to use a 
CollectNodesVisitor
to search the whereClause for any SubqueryNodes.  The above example 
demonstrates why
such a visitor would be helpful, as opposed to just checking directly for a 
SubqueryNode...

So to answer Dyre's question, yes, I think a master update will be needed.  But 
further
inspection of subqueryFlattening.sql shows that the 4c patch may need a few more
tweaks, after all...

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
Assignee: Thomas Nielsen
 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, 
 derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, 
 derby-3301-4c.diff, derby-3301-test-1.diff, derby-3301-test-1.stat, 
 derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, 
 derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND

[jira] Commented: (DERBY-3357) Reduce runtime of jdbcapi.DataSourceTest


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

Daniel John Debrunner commented on DERBY-3357:
--

This test also has some schema setup in its setup and teardown methods which of 
course will be run once per fixture. However from a quick look only a handful 
of fixtures need the schema setup. This also makes the test slower than it 
could be, maybe the setup could be one time by using the decorateSQL method of 
CleanDatabaseTestSetup.

Another minor issue is that a number of fixtures that are specific to client 
are run on embedded as well but do nothing due to a check in the test fixture 
code. The normal way of handling these is to only run  them in network server 
mode.

 Reduce runtime of jdbcapi.DataSourceTest
 

 Key: DERBY-3357
 URL: https://issues.apache.org/jira/browse/DERBY-3357
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Trivial
 Fix For: 10.4.0.0

 Attachments: derby-3357-1a-lower_lock_timeout.diff


 Two tests in DataSoureTest are waiting for a lock timeout. The runtime of the 
 suite could be reduced by setting the lock timeout to a lower value.

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

[jira] Assigned: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name


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

Bryan Pendleton reassigned DERBY-3355:
--

Assignee: Bryan Pendleton

 Alter Column ... NULL ignores double quotes around column name
 --

 Key: DERBY-3355
 URL: https://issues.apache.org/jira/browse/DERBY-3355
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.1.4
 Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton

 ' is not a column in the target table., SQL State: 42X04, Error Code: -1
 Hi:
 I think I have isolated a bug involving the use of double quotes to define a 
 column name. Here s the SQL to reproduce the bug, followed by the error 
 message generated by the final SQL statement. In order to make the bug go 
 away, eliminate all use of double quotes in the SQL statements below. Note 
 that the identical alter statement succeeds before the insert, and fail 
 after. I have spent a long time trying to isolate this problem, so please 
 take a look.
 CREATE TABLE Table2
 (
c VARCHAR(32672)
 );
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 INSERT INTO Table2(c) VALUES('yo');
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012, 
 Building output: 0
 Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 1 Row(s) Inserted
 Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009, 
 Building output: 0
 Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Error: java.sql.SQLException: Column 'C' is either not in any table in the 
 FROM list or appears within a join specification and is outside the scope of 
 the join specification or appears in a HAVING clause and is not in the GROUP 
 BY list. If this is a CREATE or ALTER TABLE  statement then 'C' is not a 
 column in the target table., SQL State: 42X04, Error Code: -1
 -Inline Message Follows-
 Geoff hendrey wrote:
  I think I have isolated a bug involving the use of double quotes to
  define a column name.
 Hi Geoff, I agree, that is definitely a bug. Your script reproduces
 the problem for me, on the current Derby trunk.
 It appears that AlterTableConstantAction.validateNotNullConstraint
 is internally generating and executing a statement of the form:
 select count(*) from tab where not (col is not null)
 The code which generates this SQL staement is not properly enclosing
 the column name in double quotes, as you noticed, so the compiler
 converts the column name to upper case, and gets the no-such-column error.
 Can you open a problem report in Jira so that we can track this down
 and get it fixed?
 http://db.apache.org/derby/DerbyBugGuidelines.html
 thanks,
 bryan

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

[jira] Commented: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)


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

V.Narayanan commented on DERBY-3359:


How will MAX and MID be set? Do you intend for these to be hardcoded 
constants, properties that can be decided by the user or something else?

I expect them to be harcoded constants for the first version of the replication 
release.
An improvement would be to make MID user configurable. 

MAX can be derived from this I guess? (Maybe we should make sure that
 MAX  DEFAULT_NUMBER_LOG_BUFFERS*MID ref. spec above).

For the first release (atleast for the first version of this patch) I was 
hoping that if I do not get 
any suggestions I will use a value of 50ms for MID.

 The log shipper needs to be modified to vary the shipping intervals 
 dynamically (based on load)
 ---

 Key: DERBY-3359
 URL: https://issues.apache.org/jira/browse/DERBY-3359
 Project: Derby
  Issue Type: Sub-task
Reporter: V.Narayanan
Assignee: V.Narayanan



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

[jira] Commented: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t


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

Kathey Marsden commented on DERBY-3243:
---

Oystein

With respect to the wrapping locator generator, I think it should be
possible to reuse locators that have been released. Hence, one way to
solve this is to start at 0 when it wraps, and iterate until an unused
locator is found.

Still the test case attached to this issue would fail as there are no calls to 
Clob.free() since it appears to be written against jdk1.5. The core problem is 
that we are limitted to 32K entries. I was looking at the spec at section 
5.6.5.13 and if I read that correctly (which  perhaps I am not) we are limitted 
to 4 bytes for the locator.  I am not sure how to get around this hard limit.

 

 (jdbc net client) exception during normal iteration through ResultSet of 
 select * from t
 

 Key: DERBY-3243
 URL: https://issues.apache.org/jira/browse/DERBY-3243
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.3.2.1
 Environment: -- Java Information --
 Java Version:1.4.2_03
 Java Vendor: Sun Microsystems Inc.
 Java home:   C:\Programme\Java\j2re1.4.2_03
 Java classpath:  derbyclient.jar
 OS name: Windows XP
 OS architecture: x86
 OS version:  5.1
 Java user name:  cbdqok
 Java user home:  C:\Dokumente und Einstellungen\cbdqok
 Java user dir:   D:\users\cbdqok\privat\osj\lib_derby_net\lib
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.4
 - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 - 
 (561794)
 --
 - Locale Information -
 --
Reporter: Oliver Seidel
Priority: Critical
 Attachments: derby-3243_fix_double_hashmap_entry_diff.txt, 
 derby-3243_fix_double_hashmap_entry_stat.txt


 Thanks again to the DERBY developers.
 For my convenience I use the client/server variant of DERBY.  This is where 
 the error occurs.  I have temporarily alleviated the problem for my case by 
 using the embedded version.
 I'm forced to use outlook and have built a program which siphons the messages 
 into a derby database (phase 1 -- table has two varchar fields and a clob).  
 When reading them back (phase 2 -- simple select of all records in no 
 particular order, all 3 attributes), it has developed an exception.  This is 
 a result of data volume.  I have reduced the problem to a single 
 demonstration program.
 This behaviour, and the fact that the error is not a DERBY Exception, but a 
 proper exception coming back from the JDBC call, leads me to the diagnosis 
 that it is a derby network client jdbc problem.
 The problem has been reproduced once by Bryan Pendleton: 
 http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
 I'll try to attach the code error.java; it can also be found on: 
 http://www.os1.net/error.java
 Please use as follows:
 javac -classpath derby.jar:derbynet.jar error.java
 java -cp .:derby.jar:derbynet.jar error
 It will create a directory test_db and fill it with approx 120mb data.
 Then you will observe the failure. 
 /* -*- Mode:Java; c-basic-offset:8 -*- */
 // 
 
 public class error {
   // 
 
   public static final int port = 1527;
   public static final String host = 127.0.0.1;
   // 
 
   public static void log(String x) { System.out.println(x); };
   // 
 
   public static void log_stacktrace(Exception e) {
 java.io.StringWriter sw = new java.io.StringWriter();
 java.io.PrintWriter pw = new java.io.PrintWriter(sw);
 e.printStackTrace(pw);
 log(sw.toString());
   };
   // 
 
   public static void start_server() {
   try {
   org.apache.derby.drda.NetworkServerControl server =
   new 
 org.apache.derby.drda.NetworkServerControl(java.net.InetAddress.getByName(host),port);
   server.start(null);
   try { java.lang.Thread.sleep(5000); } catch (Exception 
 e) { };
   log(started DERBY on

[jira] Issue Comment Edited: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t

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

oysteing edited comment on DERBY-3243 at 1/29/08 7:18 AM:
-

I have not time to look at the details of this problem today, but I
thought I would write up a few things based on what I remember from
reviewing this work.

I am not sure if it is a good idea, but the locator mapping table is
used for two separate issues:

1. It used by the network server to store the mapping from locator
by client to EmbedBlob/EmbedClob. This is used by stored
procedures that is called by the client for LOB operations.

2. It is used by the embedded driver to store references to LOB
objects that due to their size temporarily spills to disk. This
is done so that the temporary files can be cleaned up on
commit/rollback.

To me it sounds like the item 2. is implemented so that all LOB
objects are stored in the mapping table, not just those that need
clean-up. (I am guessing, I have not checked the code). That would
make two entries for every client LOB.

With respect to the wrapping locator generator, I think it should be
possible to reuse locators that have been released. Hence, one way to
solve this is to start at 0 when it wraps, and iterate until an unused
locator is found.

was (Author: oysteing):
I have time to look at the details of this problem today, but I
thought I would write up a few things based on what I remember from
reviewing this work.

I am not sure if it is a good idea, but the locator mapping table is
used for two separate issues:

1. It used by the network server to store the mapping from locator
by client to EmbedBlob/EmbedClob. This is used by stored
procedures that is called by the client for LOB operations.

(jdbc net client) exception during normal iteration through ResultSet of
select * from t

Key: DERBY-3243
URL: https://issues.apache.org/jira/browse/DERBY-3243
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.2.1
Environment: -- Java Information --
Java Version:1.4.2_03
Java Vendor: Sun Microsystems Inc.
Java home: C:\Programme\Java\j2re1.4.2_03
Java classpath: derbyclient.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: cbdqok
Java user home: C:\Dokumente und Einstellungen\cbdqok
Java user dir: D:\users\cbdqok\privat\osj\lib_derby_net\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.4
- Derby Information
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 -
(561794)
--
- Locale Information -
--
Reporter: Oliver Seidel
Priority: Critical
Attachments: derby-3243_fix_double_hashmap_entry_diff.txt,
derby-3243_fix_double_hashmap_entry_stat.txt

Thanks again to the DERBY developers.
For my convenience I use the client/server variant of DERBY. This is where
the error occurs. I have temporarily alleviated the problem for my case by
using the embedded version.
I'm forced to use outlook and have built a program which siphons the messages
into a derby database (phase 1 -- table has two varchar fields and a clob).
When reading them back (phase 2 -- simple select of all records in no
particular order, all 3 attributes), it has developed an exception. This is
a result of data volume. I have reduced the problem to a single
demonstration program.
This behaviour, and the fact that the error is not a DERBY Exception, but a
proper exception coming back from the JDBC call, leads me to the diagnosis
that it is a derby network client jdbc problem.
The problem has been reproduced once by Bryan Pendleton:

[jira] Commented: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t


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

Øystein Grøvlen commented on DERBY-3243:


I have time to look at the details of this problem today, but I
thought I would write up a few things based on what I remember from
reviewing this work.

I am not sure if it is a good idea, but the locator mapping table is
used for two separate issues:

  1. It used by the network server to store the mapping from locator
 by client to EmbedBlob/EmbedClob.  This is used by stored
 procedures that is called by the client for LOB operations.

  2. It is used by the embedded driver to store references to LOB
 objects that due to their size temporarily spills to disk.  This
 is done so that the temporary files can be cleaned up on
 commit/rollback.

To me it sounds like the item 2. is implemented so that all LOB
objects are stored in the mapping table, not just those that need
clean-up.  (I am guessing, I have not checked the code).  That would
make two entries for every client LOB.

With respect to the wrapping locator generator, I think it should be
possible to reuse locators that have been released.  Hence, one way to
solve this is to start at 0 when it wraps, and iterate until an unused
locator is found.
 
   


 (jdbc net client) exception during normal iteration through ResultSet of 
 select * from t
 

 Key: DERBY-3243
 URL: https://issues.apache.org/jira/browse/DERBY-3243
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.3.2.1
 Environment: -- Java Information --
 Java Version:1.4.2_03
 Java Vendor: Sun Microsystems Inc.
 Java home:   C:\Programme\Java\j2re1.4.2_03
 Java classpath:  derbyclient.jar
 OS name: Windows XP
 OS architecture: x86
 OS version:  5.1
 Java user name:  cbdqok
 Java user home:  C:\Dokumente und Einstellungen\cbdqok
 Java user dir:   D:\users\cbdqok\privat\osj\lib_derby_net\lib
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.4
 - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 - 
 (561794)
 --
 - Locale Information -
 --
Reporter: Oliver Seidel
Priority: Critical
 Attachments: derby-3243_fix_double_hashmap_entry_diff.txt, 
 derby-3243_fix_double_hashmap_entry_stat.txt


 Thanks again to the DERBY developers.
 For my convenience I use the client/server variant of DERBY.  This is where 
 the error occurs.  I have temporarily alleviated the problem for my case by 
 using the embedded version.
 I'm forced to use outlook and have built a program which siphons the messages 
 into a derby database (phase 1 -- table has two varchar fields and a clob).  
 When reading them back (phase 2 -- simple select of all records in no 
 particular order, all 3 attributes), it has developed an exception.  This is 
 a result of data volume.  I have reduced the problem to a single 
 demonstration program.
 This behaviour, and the fact that the error is not a DERBY Exception, but a 
 proper exception coming back from the JDBC call, leads me to the diagnosis 
 that it is a derby network client jdbc problem.
 The problem has been reproduced once by Bryan Pendleton: 
 http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
 I'll try to attach the code error.java; it can also be found on: 
 http://www.os1.net/error.java
 Please use as follows:
 javac -classpath derby.jar:derbynet.jar error.java
 java -cp .:derby.jar:derbynet.jar error
 It will create a directory test_db and fill it with approx 120mb data.
 Then you will observe the failure. 
 /* -*- Mode:Java; c-basic-offset:8 -*- */
 // 
 
 public class error {
   // 
 
   public static final int port = 1527;
   public static final String host = 127.0.0.1;
   // 
 
   public static void log(String x) { System.out.println(x); };
   // 
 
   public static void log_stacktrace(Exception e) {
 java.io.StringWriter sw = new java.io.StringWriter();
 java.io.PrintWriter pw = new java.io.PrintWriter(sw);
 e.printStackTrace(pw);
 log(sw.toString());
   };

[jira] Updated: (DERBY-3324) JDBC statement cache implementation

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

Kristian Waagan updated DERBY-3324:
---

Attachment: derby-3324-1e-jdbc_statementcache.diff

Yet another version of the patch...
'derby-3324-1e-jdbc_statementcache.diff' does not enable the tests, because the
classes being tested are not pulled into the jar files. The reason for this is
that they are not used by any other classes yet.
Instead of doing something explicit to include the files, I will wait until
they are being used.
Note that the tests themselves are still in the patch.

JDBC statement cache implementation
---

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

[jira] Commented: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable

2008-01-29 Thread Mayuresh Nirhali (JIRA)


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

Mayuresh Nirhali commented on DERBY-2592:
-

Jazarine,

On a quick look at your patch, I see a diff for nbproject/project.xml which is 
not part of derby code.
So, make sure you submit patch that only contains changes to files which are 
part of derby codebase. Please submit a new patch with only changes to derby 
relevant files.

Also, Have you tested the DOC files after your change. Build the doc target, 
and see the generated HTML page... Mention if any other testing you have done.

 Wrong description of IndexName field in public JavaDoc for LockTable
 

 Key: DERBY-2592
 URL: https://issues.apache.org/jira/browse/DERBY-2592
 Project: Derby
  Issue Type: Bug
  Components: Javadoc
Affects Versions: 10.3.1.4
Reporter: Olav Sandstaa
Assignee: Jazarine Jamal
Priority: Trivial
 Attachments: DERBY-2592.diff


 The public JavaDoc for LockTable says the following in the description of the 
 INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE:
INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the 
 index, this can only happen if this is not a user transaction.
 I think the last part is wrong. Normal user transactions might also have a 
 value in the INDEXNAME. For example, here is part of the lock table for three 
 user transactions:
 XID |TYPE |MODE|TABLENAME |LOCKNAME  |STATE|TABLETYPE|INDEXNAME
 -
 186 |ROW  |X   |T2|(1,9) |GRANT|T|NULL
 184 |ROW  |S   |T2|(1,9) |WAIT |T|NULL
 188 |ROW  |X   |T1|(1,11)|GRANT|T|NULL 
 186 |ROW  |S   |T1|(1,11)|WAIT |T|NULL
 186 |ROW  |S   |T1|(1,1) |GRANT|T|SQL070425023213370 
 188 |ROW  |S   |T1|(1,1) |GRANT|T|SQL070425023213370 
 184 |ROW  |X   |T1|(1,7) |GRANT|T|NULL
 188 |ROW  |S   |T1|(1,7) |WAIT |T|NULL   
 Two of the lock entries have an index. I expect this to be the Scan lock that 
 have been set during traversal of the B-tree.
 Proposed fix: remove the last part of the sentence.

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

[jira] Updated: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable

2008-01-29 Thread Jazarine Jamal (JIRA)


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

Jazarine Jamal updated DERBY-2592:
--

Attachment: DERBY-2592.diff

I just removed the last part of the sentence and now I think the documentation 
is right..

 Wrong description of IndexName field in public JavaDoc for LockTable
 

 Key: DERBY-2592
 URL: https://issues.apache.org/jira/browse/DERBY-2592
 Project: Derby
  Issue Type: Bug
  Components: Javadoc
Affects Versions: 10.3.1.4
Reporter: Olav Sandstaa
Assignee: Jazarine Jamal
Priority: Trivial
 Attachments: DERBY-2592.diff


 The public JavaDoc for LockTable says the following in the description of the 
 INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE:
INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the 
 index, this can only happen if this is not a user transaction.
 I think the last part is wrong. Normal user transactions might also have a 
 value in the INDEXNAME. For example, here is part of the lock table for three 
 user transactions:
 XID |TYPE |MODE|TABLENAME |LOCKNAME  |STATE|TABLETYPE|INDEXNAME
 -
 186 |ROW  |X   |T2|(1,9) |GRANT|T|NULL
 184 |ROW  |S   |T2|(1,9) |WAIT |T|NULL
 188 |ROW  |X   |T1|(1,11)|GRANT|T|NULL 
 186 |ROW  |S   |T1|(1,11)|WAIT |T|NULL
 186 |ROW  |S   |T1|(1,1) |GRANT|T|SQL070425023213370 
 188 |ROW  |S   |T1|(1,1) |GRANT|T|SQL070425023213370 
 184 |ROW  |X   |T1|(1,7) |GRANT|T|NULL
 188 |ROW  |S   |T1|(1,7) |WAIT |T|NULL   
 Two of the lock entries have an index. I expect this to be the Scan lock that 
 have been set during traversal of the B-tree.
 Proposed fix: remove the last part of the sentence.

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

[jira] Commented: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name


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

Daniel John Debrunner commented on DERBY-3355:
--

Any explanation for why the same statement worked once with c and then failed 
later?

 Alter Column ... NULL ignores double quotes around column name
 --

 Key: DERBY-3355
 URL: https://issues.apache.org/jira/browse/DERBY-3355
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.1.4
 Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
 Attachments: patch.diff


 ' is not a column in the target table., SQL State: 42X04, Error Code: -1
 Hi:
 I think I have isolated a bug involving the use of double quotes to define a 
 column name. Here s the SQL to reproduce the bug, followed by the error 
 message generated by the final SQL statement. In order to make the bug go 
 away, eliminate all use of double quotes in the SQL statements below. Note 
 that the identical alter statement succeeds before the insert, and fail 
 after. I have spent a long time trying to isolate this problem, so please 
 take a look.
 CREATE TABLE Table2
 (
c VARCHAR(32672)
 );
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 INSERT INTO Table2(c) VALUES('yo');
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012, 
 Building output: 0
 Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 1 Row(s) Inserted
 Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009, 
 Building output: 0
 Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Error: java.sql.SQLException: Column 'C' is either not in any table in the 
 FROM list or appears within a join specification and is outside the scope of 
 the join specification or appears in a HAVING clause and is not in the GROUP 
 BY list. If this is a CREATE or ALTER TABLE  statement then 'C' is not a 
 column in the target table., SQL State: 42X04, Error Code: -1
 -Inline Message Follows-
 Geoff hendrey wrote:
  I think I have isolated a bug involving the use of double quotes to
  define a column name.
 Hi Geoff, I agree, that is definitely a bug. Your script reproduces
 the problem for me, on the current Derby trunk.
 It appears that AlterTableConstantAction.validateNotNullConstraint
 is internally generating and executing a statement of the form:
 select count(*) from tab where not (col is not null)
 The code which generates this SQL staement is not properly enclosing
 the column name in double quotes, as you noticed, so the compiler
 converts the column name to upper case, and gets the no-such-column error.
 Can you open a problem report in Jira so that we can track this down
 and get it fixed?
 http://db.apache.org/derby/DerbyBugGuidelines.html
 thanks,
 bryan

-- 
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-01-29 Thread Thomas Nielsen (JIRA)


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

Thomas Nielsen commented on DERBY-2998:
---

 The 9 patch attached does not evaluate WHERE clauses on expression columns in 
 the materialized subquery resultset correctly.

The predicate of the outer select is flagged as pushable, and ends up being 
pushed into the subquery for evaluation. This is wrong for window functions, 
and possibly also for any where clause over a materialized resultset.

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


 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-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t


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

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

 It seems to me that we would have the same problem (albeit further removed) 
 if we roll over the lob key at 32K. I will look at the DRDA spec and see if 
 there is an opportunity to send a larger value.

Yes, we would have the same problem. If we find a way to use e.g. 4-byte 
integers it would only manifest itself if someone retrieves a lob, keeps it 
while retrieving billions of other lobs in the same connection, and then tries 
to access the first lob. In that case, I think it's highly unlikely that 
someone will be bitten by it.

I think the rest of the patch looks OK (except there's a typo in the javadoc 
for EmbedClob.getLocator(): loctor - locator, and in EngineBlob/EngineClob: 
getLobLobMapping() - getLOBMapping()).

Do you think we should use getLocator() instead of addLOBMapping() in 
LobStoredProcedure.BLOBCREATELOCATOR() and CLOBCREATELOCATOR() as well? Seems 
like the Blobs/Clobs they create already have called addLOBMapping() in their 
constructors.

Another thing I came to think about: Would it be better to remove 
addLOBMapping() from the constructors in EmbedBlob/EmbedClob and instead call 
it lazily from getLocator()? Something like:

  public int getLocator() {
  if (locator == -1) {
  locator = getEmbedConnection().addLOBMapping(this);
  }
  return locator;
  }

Then we'd also remove the overhead of maintaining the lob mapping in embedded 
mode.

 (jdbc net client) exception during normal iteration through ResultSet of 
 select * from t
 

 Key: DERBY-3243
 URL: https://issues.apache.org/jira/browse/DERBY-3243
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.3.2.1
 Environment: -- Java Information --
 Java Version:1.4.2_03
 Java Vendor: Sun Microsystems Inc.
 Java home:   C:\Programme\Java\j2re1.4.2_03
 Java classpath:  derbyclient.jar
 OS name: Windows XP
 OS architecture: x86
 OS version:  5.1
 Java user name:  cbdqok
 Java user home:  C:\Dokumente und Einstellungen\cbdqok
 Java user dir:   D:\users\cbdqok\privat\osj\lib_derby_net\lib
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.4
 - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 - 
 (561794)
 --
 - Locale Information -
 --
Reporter: Oliver Seidel
Priority: Critical
 Attachments: derby-3243_fix_double_hashmap_entry_diff.txt, 
 derby-3243_fix_double_hashmap_entry_stat.txt


 Thanks again to the DERBY developers.
 For my convenience I use the client/server variant of DERBY.  This is where 
 the error occurs.  I have temporarily alleviated the problem for my case by 
 using the embedded version.
 I'm forced to use outlook and have built a program which siphons the messages 
 into a derby database (phase 1 -- table has two varchar fields and a clob).  
 When reading them back (phase 2 -- simple select of all records in no 
 particular order, all 3 attributes), it has developed an exception.  This is 
 a result of data volume.  I have reduced the problem to a single 
 demonstration program.
 This behaviour, and the fact that the error is not a DERBY Exception, but a 
 proper exception coming back from the JDBC call, leads me to the diagnosis 
 that it is a derby network client jdbc problem.
 The problem has been reproduced once by Bryan Pendleton: 
 http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
 I'll try to attach the code error.java; it can also be found on: 
 http://www.os1.net/error.java
 Please use as follows:
 javac -classpath derby.jar:derbynet.jar error.java
 java -cp .:derby.jar:derbynet.jar error
 It will create a directory test_db and fill it with approx 120mb data.
 Then you will observe the failure. 
 /* -*- Mode:Java; c-basic-offset:8 -*- */
 // 
 
 public class error {
   // 
 
   public static final int port = 1527;
   public static final String host = 127.0.0.1;
   // 
 
   public static void log(String x) { System.out.println(x); };
   // 
 
   public static void

[jira] Issue Comment Edited: (DERBY-3359) The log shipper needs to be modified to vary the shipping intervals dynamically (based on load)

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

narayanan edited comment on DERBY-3359 at 1/29/08 2:43 AM:
-

Introduction

Basic Idea
--

The Log Buffer will notify the Log Shipper when a buffer is full. When the Log
Shipper gets this notification it will decide the action to be done the
following
way

1) It will retrieve the fill information from the Log Buffer. The fill
information
is a indicator of how full the log is at any point of time.

fill information = (full buffers/Total Buffers)*100

2) If the fill information is greater than 80 the log shipper will ship log
records
until the fill information returns a value less than 80. There will be no
time
delay between the ships.

3) If the fill information is less than 80 but greater than 10 the log shipper
will
ship with a MID ms delay. (*MID has not been decided yet*)

4) If the fill information is less than 10 the log shipper will ship with a MAX
ms delay
or when a buffer becomes full whichever comes first. The delay however will
not be
smaller than MID.
(*MAX MID exact values of MAX has not been decided yet*).

Note: MID is a value that is only as large as not to affect the performance of
the master database
significantly.

was (Author: narayanan):
Introduction

Basic Idea
--

The Log Buffer will notify the Log Shipper when a buffer is full. When the Log
Shipper gets this notification it will decide the action to be done the
following
way

1) It will retrieve the fill information from the Log Buffer. The fill
information
is a indicator of how full the log is at any point of time.

fill information = (full buffers/Total Buffers)*100

2) If the fill information is greater than 80 the log shipper will ship log
records
until the fill information returns a value less than 80. There will be no
time
delay between the ships.

3) If the fill information is less than 80 but greater than 10 the log shipper
will
ship with a MID ms delay. (*MID has not been decided yet*)

Note: MID is a value that is only as large as not to affect the performance of
the master database
significantly.

The log shipper needs to be modified to vary the shipping intervals
dynamically (based on load)
---

Key: DERBY-3359
URL: https://issues.apache.org/jira/browse/DERBY-3359
Project: Derby
Issue Type: Sub-task
Reporter: V.Narayanan
Assignee: V.Narayanan

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

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

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

John H. Embretsen commented on DERBY-1387:
--

Hi Rick,

Regarding the scenarios 1) and 2) you outlined wrt. users trying to enable JMX
on jdk1.4, I have (for now) solved this by adding checks in the monitor for the
availability of the classes java.lang.management.ManagementFactory and
javax.management.ObjectName. The latter is part of the reference
implementation, but the former is not, and both are currently required by
Derby's JMX functionality.

If any of these classes are not present in the classpath, a warning is written
to derby.log, and Derby boots normally without JMX enabled. In addition, there
is a check in NetworkServerControl, writing a warning to the server console if
the JMX module is not available (jdk1.4). Exactly what these warning messages
should say and how to issue them may need some tweaking/polishing, I presume...

I will upload a new patch shortly, including these changes. I'll also try to
clarify the (lack of) jdk1.4 support in an update to the functional spec.

Add JMX extensions to Derby
---

Key: DERBY-1387
URL: https://issues.apache.org/jira/browse/DERBY-1387
Project: Derby
Issue Type: New Feature
Components: Services
Reporter: Sanket Sharma
Assignee: John H. Embretsen
Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff,
DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff,
DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip,
DERBY-1387-7.zip, DERBY-1387-8.zip, derbyjmx.patch, jmx.diff, jmx.stat,
jmxFuncspec.html, Requirements for JMX Updated.html, Requirements for
JMX.html, Requirements for JMX.zip

This is a draft requirement specification for adding monitoring and
management extensions to Apache Derby using JMX. The requirements document
has been uploaded on JIRA as well as the Derby Wiki page at
http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX
Developers and Users are requested to please look at the document (feature
list in particular) and add their own rating to features by adding a coloumn
to the table.
Comments are welcome.

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

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

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

Component/s: Replication

 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

 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=12563456#action_12563456
 ] 

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

I think this is caused by not unplugging the Socket in MasterController when 
the master replication functionality is turned off.


 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

 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-3301) Incorrect result from query with nested EXIST

2008-01-29 Thread Craig Russell (JIRA)


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

Craig Russell commented on DERBY-3301:
--

I'd like to summarize my understanding of the patch.

If you have an EXISTS nested inside an EXISTS, the optimized inversion of the 
query execution plan does not occur. Instead, the natural execution plan is 
performed. That is, the outer tables are iterated and for each candidate tuple 
of the joined tables, the EXISTS is performed. 

For each EXISTS check, the scans are reinitialized and there might not be any 
clues as to exactly where in the outer scan the EXISTS is being invoked. This 
might yield sub-optimal performance compared to an optimized inverted scan.

Also, I'm trying to get some more test cases by putting additional criteria 
into the EXISTS and running the query in debug mode and filtering the output. 
It's slower than I expected but I'll continue if it will help.

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
Assignee: Thomas Nielsen
 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, 
 derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, 
 derby-3301-4c.diff, derby-3301-test-1.diff, derby-3301-test-1.stat, 
 derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, 
 derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows

[jira] Updated: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name


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

Bryan Pendleton updated DERBY-3355:
---

Attachment: patch.diff

Attached is 'patch.diff', a patch proposal.

The patch modifies AlterTableConstantAction.validateNotNullConstraint
to enclose the column name in double quotes when generating
SQL on-the-fly.

The patch also adds a variety of test cases to altertable.sql, based
on the repro script for this issue, using a variety of table and column
names in both mixed case and all upper case.

I'm still running the full regression suite; I'll report back on the results.


 Alter Column ... NULL ignores double quotes around column name
 --

 Key: DERBY-3355
 URL: https://issues.apache.org/jira/browse/DERBY-3355
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.1.4
 Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
 Attachments: patch.diff


 ' is not a column in the target table., SQL State: 42X04, Error Code: -1
 Hi:
 I think I have isolated a bug involving the use of double quotes to define a 
 column name. Here s the SQL to reproduce the bug, followed by the error 
 message generated by the final SQL statement. In order to make the bug go 
 away, eliminate all use of double quotes in the SQL statements below. Note 
 that the identical alter statement succeeds before the insert, and fail 
 after. I have spent a long time trying to isolate this problem, so please 
 take a look.
 CREATE TABLE Table2
 (
c VARCHAR(32672)
 );
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 INSERT INTO Table2(c) VALUES('yo');
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012, 
 Building output: 0
 Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 1 Row(s) Inserted
 Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009, 
 Building output: 0
 Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Error: java.sql.SQLException: Column 'C' is either not in any table in the 
 FROM list or appears within a join specification and is outside the scope of 
 the join specification or appears in a HAVING clause and is not in the GROUP 
 BY list. If this is a CREATE or ALTER TABLE  statement then 'C' is not a 
 column in the target table., SQL State: 42X04, Error Code: -1
 -Inline Message Follows-
 Geoff hendrey wrote:
  I think I have isolated a bug involving the use of double quotes to
  define a column name.
 Hi Geoff, I agree, that is definitely a bug. Your script reproduces
 the problem for me, on the current Derby trunk.
 It appears that AlterTableConstantAction.validateNotNullConstraint
 is internally generating and executing a statement of the form:
 select count(*) from tab where not (col is not null)
 The code which generates this SQL staement is not properly enclosing
 the column name in double quotes, as you noticed, so the compiler
 converts the column name to upper case, and gets the no-such-column error.
 Can you open a problem report in Jira so that we can track this down
 and get it fixed?
 http://db.apache.org/derby/DerbyBugGuidelines.html
 thanks,
 bryan

-- 
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-01-29 Thread jira

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


Key Summary
DERBY-3301  Incorrect result from query with nested EXIST
https://issues.apache.org/jira/browse/DERBY-3301
DERBY-3243  (jdbc net client) exception during normal iteration through 
ResultSet of select * from t
https://issues.apache.org/jira/browse/DERBY-3243
DERBY-2683  tools and utilities guide: ij.URLCheck's list of checked attributes 
is not correct
https://issues.apache.org/jira/browse/DERBY-2683
DERBY-2592  Wrong description of IndexName field in public JavaDoc for LockTable
https://issues.apache.org/jira/browse/DERBY-2592
DERBY-3205  Replication: Add connection url command options for starting, 
stopping slave and for failover
https://issues.apache.org/jira/browse/DERBY-3205
DERBY-3288  wrong query result in presence of a unique index
https://issues.apache.org/jira/browse/DERBY-3288
DERBY-3088  convert to junit, or otherwise eliminate version in tests which 
require an update of the master in the release management process
https://issues.apache.org/jira/browse/DERBY-3088
DERBY-2760  Clean-up issues for UTF8Util.java
https://issues.apache.org/jira/browse/DERBY-2760
DERBY-3325  Add 'maxStatements' property to ClientConnectionPoolDataSource
https://issues.apache.org/jira/browse/DERBY-3325
DERBY-3189  Replication: Add connection url command options for starting and 
stopping master
https://issues.apache.org/jira/browse/DERBY-3189
DERBY-3137  SQL roles: add catalog support
https://issues.apache.org/jira/browse/DERBY-3137
DERBY-3169  Add documentation for replication
https://issues.apache.org/jira/browse/DERBY-3169
DERBY-2871  XATransactionTest gets XaException: Error executing a 
XAResource.commit(), server returned XAER_PROTO.
https://issues.apache.org/jira/browse/DERBY-2871
DERBY-3117  Adjust master build script to require the Java 5 compiler to build 
Derby
https://issues.apache.org/jira/browse/DERBY-3117
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-3083  Network server demands a file called derbynet.jar in classpath
https://issues.apache.org/jira/browse/DERBY-3083
DERBY-3227  Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227

[jira] Updated: (DERBY-1387) Add JMX extensions to Derby


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

John H. Embretsen updated DERBY-1387:
-

Attachment: DERBY-1387-9.stat
DERBY-1387-9.diff

Uploaded a new patch, DERBY-1387-9.diff + .stat, replacing previous patches.

Changes since the previous (1387-8) patch:

 - made org.apache.derby.iapi.services.mbeans.ManagementService independent
   of JMX / jdk1.5, as explained in a previous comment. Thus, this patch
   should build just fine without requiring additional libraries, though
   the JMX features are not available in a 1.4 VM.

 - added missing MDatabase class file.

 - Changed o/a/d/impl/services/build.xml's compile_impl_services_jdk15 
   target to use the default compiler instead of jdk1.6 to compile 1.5 code,
   with java15compile.classpath as the classpath, and included the 
   1.5-specific JMX functionality (impl/services/mbeans/*) in this target.

 - added a check in FileMonitor for the presence of certain JMX classes 
   before allowing JMX to be enabled. A warning is printed to derby.log and
   (if relevant) the Network Server console if JMX support is not available 
   but derby.system.jmx=true. This probably needs some polishing, at least 
   in the FileMonitor, where I've simply called report() with a hard-coded 
   String as parameter. 

   (I may also have missed something somewhere wrt. jdk1.4 since I have
   not done any extensive testing, and I'm not fully on top of how the
   monitor/module system works at this time.)

 - improved Network Server error handling/reporting wrt. JMX

 - resolved patch incompatilbility with current trunk wrt. server.policy

 - added necessary permissions (present in server.policy) to template.policy

 - fixed typo in java/engine/org/apache/derby/impl/services/build.xml

 - removed some spurious tabs from some of the new code segments

 - fixed some Javadoc errors


There are still some TODOs for this feature, including:

 - proper authentication/authorization/system privileges support?
 - Javadoc for all interfaces (a lot is missing in e.g. MDatabaseMBean.java)
 - better error messages and message handling
 - documentation
 - testing

There are also a few other things worth mentioning/asking about, such as:

 - why does NetworkServerControlImpl.java create the MBean directly instead
   of using a factory method via the ManagementService interface?
   (contrary to Ole Gunnar's comment of 01/Aug/07 01:30 AM + funcSpec)
   Is it because the MBean requires a reference to NetworkServerControlImpl,
   and the resulting dependencies/build issues are non-trivial to solve?

 - currently, the NetworkServerControlMgmtMBean is in the same package as
   NetworkServerControlImpl, and is compiled with jdk1.4, meaning that
   this MBean cannot reference the JMX API directly (for example: Emit or
   handle Notifications). We may want to change this in a future revision
   of this feature.

 - what is special about BaseMonitor.runWithState()? That is, if the JMX
   module is started differently from other modules, why? I tried adding
   the JMX module with class dependencies to 
   org/apache/derby/modules.properties without seeing any effect; could it 
   be related to this?

 - when shutting down the server via JMX, no shutdown messages are written
   to the log or the console. If shutdown is supposed to be supported, this
   should be improved.

Anyway, since this now compiles with the current trunk and seems to run OK 
with all supported JVM versions, I intend to update the functional spec 
and work on testing next.


 Add JMX extensions to Derby
 ---

 Key: DERBY-1387
 URL: https://issues.apache.org/jira/browse/DERBY-1387
 Project: Derby
  Issue Type: New Feature
  Components: Services
Reporter: Sanket Sharma
Assignee: John H. Embretsen
 Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff, 
 DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff, 
 DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip, 
 DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat, 
 derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, Requirements for JMX 
 Updated.html, Requirements for JMX.html, Requirements for JMX.zip


 This is a draft requirement specification for adding monitoring and 
 management extensions to Apache Derby using JMX. The requirements document 
 has been uploaded on JIRA as well as the Derby Wiki page at 
 http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX
 Developers and Users are requested to please look at the document (feature 
 list in particular) and add their own rating to features by adding a coloumn 
 to the table.
 Comments are welcome.

-- 
This message is automatically

[jira] Commented: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable

2008-01-29 Thread Jazarine Jamal (JIRA)


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

Jazarine Jamal commented on DERBY-2592:
---

The problem was that there was a statement:This can only happen if this is not 
a user transaction

In the example, there are two lock entries that have an index.

Thus the whole sentence is re-framed into:

LIINDEXNAME varchar(128) - normally null.  If non-null, a lock is held on 
the index./LI

I hope this resolves the problem...

 Wrong description of IndexName field in public JavaDoc for LockTable
 

 Key: DERBY-2592
 URL: https://issues.apache.org/jira/browse/DERBY-2592
 Project: Derby
  Issue Type: Bug
  Components: Javadoc
Affects Versions: 10.3.1.4
Reporter: Olav Sandstaa
Assignee: Jazarine Jamal
Priority: Trivial
 Attachments: DERBY-2592.diff


 The public JavaDoc for LockTable says the following in the description of the 
 INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE:
INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the 
 index, this can only happen if this is not a user transaction.
 I think the last part is wrong. Normal user transactions might also have a 
 value in the INDEXNAME. For example, here is part of the lock table for three 
 user transactions:
 XID |TYPE |MODE|TABLENAME |LOCKNAME  |STATE|TABLETYPE|INDEXNAME
 -
 186 |ROW  |X   |T2|(1,9) |GRANT|T|NULL
 184 |ROW  |S   |T2|(1,9) |WAIT |T|NULL
 188 |ROW  |X   |T1|(1,11)|GRANT|T|NULL 
 186 |ROW  |S   |T1|(1,11)|WAIT |T|NULL
 186 |ROW  |S   |T1|(1,1) |GRANT|T|SQL070425023213370 
 188 |ROW  |S   |T1|(1,1) |GRANT|T|SQL070425023213370 
 184 |ROW  |X   |T1|(1,7) |GRANT|T|NULL
 188 |ROW  |S   |T1|(1,7) |WAIT |T|NULL   
 Two of the lock entries have an index. I expect this to be the Scan lock that 
 have been set during traversal of the B-tree.
 Proposed fix: remove the last part of the sentence.

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

[jira] Commented: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name


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

Bryan Pendleton commented on DERBY-3355:


ALTER TABLE conditionally checks the not null constraint. It first looks
to see if the table is empty or not, by calling getSemiRowCount, which
classifies the table into having 0, 1, or 1 rows. Then, if the table has
at least 1 row, it generates and executes the problematic SQL with
the unquoted column name.

So the first invocation in the repro script succeeds because the table is empty.

The code in question is around line 2420 of AlterTableConstantAction.java:

if (cd.getType().isNullable())
{
if (numRows  0)
{
// already found a nullable column so add AND
if (foundNullable)
constraintText.append( AND );
constraintText.append(\ + columnNames[colCtr] +
\ IS NOT NULL );
}
foundNullable = true;
nullCols[colCtr] = true;
}

The first time through the repro script, numRows is 0.


 Alter Column ... NULL ignores double quotes around column name
 --

 Key: DERBY-3355
 URL: https://issues.apache.org/jira/browse/DERBY-3355
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.1.4
 Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
 Attachments: patch.diff


 ' is not a column in the target table., SQL State: 42X04, Error Code: -1
 Hi:
 I think I have isolated a bug involving the use of double quotes to define a 
 column name. Here s the SQL to reproduce the bug, followed by the error 
 message generated by the final SQL statement. In order to make the bug go 
 away, eliminate all use of double quotes in the SQL statements below. Note 
 that the identical alter statement succeeds before the insert, and fail 
 after. I have spent a long time trying to isolate this problem, so please 
 take a look.
 CREATE TABLE Table2
 (
c VARCHAR(32672)
 );
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 INSERT INTO Table2(c) VALUES('yo');
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012, 
 Building output: 0
 Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 1 Row(s) Inserted
 Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009, 
 Building output: 0
 Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Error: java.sql.SQLException: Column 'C' is either not in any table in the 
 FROM list or appears within a join specification and is outside the scope of 
 the join specification or appears in a HAVING clause and is not in the GROUP 
 BY list. If this is a CREATE or ALTER TABLE  statement then 'C' is not a 
 column in the target table., SQL State: 42X04, Error Code: -1
 -Inline Message Follows-
 Geoff hendrey wrote:
  I think I have isolated a bug involving the use of double quotes to
  define a column name.
 Hi Geoff, I agree, that is definitely a bug. Your script reproduces
 the problem for me, on the current Derby trunk.
 It appears that AlterTableConstantAction.validateNotNullConstraint
 is internally generating and executing a statement of the form:
 select count(*) from tab where not (col is not null)
 The code which generates this SQL staement is not properly enclosing
 the column name in double quotes, as you noticed, so the compiler
 converts the column name to upper case, and gets the no-such-column error.
 Can you open a problem report in Jira so that we can track this down
 and get it fixed?
 http://db.apache.org/derby/DerbyBugGuidelines.html
 thanks,
 bryan

-- 
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=12563458#action_12563458
 ] 

Ole Solberg commented on DERBY-3358:


If in this state we do a stopMaster command a NPE is thrown:

CONNECT 'jdbc:derby://atum11:/test;stopMaster=true';
ERROR XJ001: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: 
java.lang.NullPointerExceptionXJ001.U

master derby.log:
2008-01-29 10:24:07.228 GMT Thread[DRDAConnThread_4,5,main] (XID = 423), 
(SESSIONID = 4), (DATABASE = test), (DRDAID = {6}), Cleanup action starting
java.lang.NullPointerException
at 
org.apache.derby.impl.services.replication.master.MasterController.stopMaster(MasterController.java:213)
at 
org.apache.derby.impl.store.raw.RawStore.stopReplicationMaster(RawStore.java:526)
at 
org.apache.derby.impl.store.access.RAMAccessManager.stopReplicationMaster(RAMAccessManager.java:938)
at 
org.apache.derby.impl.db.BasicDatabase.stopReplicationMaster(BasicDatabase.java:388)
at 
org.apache.derby.impl.jdbc.EmbedConnection.handleStopReplicationMaster(EmbedConnection.java:683)
at 
org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:344)
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:211)
at 
org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
at 
org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
at 
org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090)
at 
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932)
at 
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
Cleanup action completed
2008-01-29 10:24:07.228 GMT Thread[DRDAConnThread_4,5,main] Cleanup action 
starting
java.lang.NullPointerException
at 
org.apache.derby.impl.services.replication.master.MasterController.stopMaster(MasterController.java:213)
at 
org.apache.derby.impl.store.raw.RawStore.stopReplicationMaster(RawStore.java:526)
at 
org.apache.derby.impl.store.access.RAMAccessManager.stopReplicationMaster(RAMAccessManager.java:938)
at 
org.apache.derby.impl.db.BasicDatabase.stopReplicationMaster(BasicDatabase.java:388)
at 
org.apache.derby.impl.jdbc.EmbedConnection.handleStopReplicationMaster(EmbedConnection.java:683)
at 
org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:344)
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:211)
at 
org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
at 
org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
at 
org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090)
at 
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932)
at 
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
Cleanup action completed
2008-01-29 10:24:07.231 GMT Thread[DRDAConnThread_4,5,main] (DATABASE = test), 
(DRDAID = {6}), Java exception: ': java.lang.NullPointerException'.


 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

 Slave and master servers started.
 startSlave:
 CONNECT

[jira] Updated: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable

2008-01-29 Thread Jazarine Jamal (JIRA)


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

Jazarine Jamal updated DERBY-2592:
--

Derby Info: [Patch Available]

 Wrong description of IndexName field in public JavaDoc for LockTable
 

 Key: DERBY-2592
 URL: https://issues.apache.org/jira/browse/DERBY-2592
 Project: Derby
  Issue Type: Bug
  Components: Javadoc
Affects Versions: 10.3.1.4
Reporter: Olav Sandstaa
Assignee: Jazarine Jamal
Priority: Trivial
 Attachments: DERBY-2592.diff


 The public JavaDoc for LockTable says the following in the description of the 
 INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE:
INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the 
 index, this can only happen if this is not a user transaction.
 I think the last part is wrong. Normal user transactions might also have a 
 value in the INDEXNAME. For example, here is part of the lock table for three 
 user transactions:
 XID |TYPE |MODE|TABLENAME |LOCKNAME  |STATE|TABLETYPE|INDEXNAME
 -
 186 |ROW  |X   |T2|(1,9) |GRANT|T|NULL
 184 |ROW  |S   |T2|(1,9) |WAIT |T|NULL
 188 |ROW  |X   |T1|(1,11)|GRANT|T|NULL 
 186 |ROW  |S   |T1|(1,11)|WAIT |T|NULL
 186 |ROW  |S   |T1|(1,1) |GRANT|T|SQL070425023213370 
 188 |ROW  |S   |T1|(1,1) |GRANT|T|SQL070425023213370 
 184 |ROW  |X   |T1|(1,7) |GRANT|T|NULL
 188 |ROW  |S   |T1|(1,7) |WAIT |T|NULL   
 Two of the lock entries have an index. I expect this to be the Scan lock that 
 have been set during traversal of the B-tree.
 Proposed fix: remove the last part of the sentence.

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

[jira] Commented: (DERBY-3361) Specifying a non-existant slaveHost for startSlave seemingly succeeds in starting slave mode.


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

Øystein Grøvlen commented on DERBY-3361:


Would it be an idea to wait in SlaveDatabase#boot until contact has been 
established between master and slave?  That would make it possible to report 
problems that occur during start-up.

 Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
 starting slave mode.
 -

 Key: DERBY-3361
 URL: https://issues.apache.org/jira/browse/DERBY-3361
 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: Jørgen Løland

 Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
 starting slave mode.
 ---
  CONNECT 
 'jdbc:derby://atum11:/test;startSlave=true;slaveHost=noSuchHost;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. 
 Slave derby.log shows a NPE:
 --
 2008-01-29 11:52:40.050 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance c013800d-0117-c563-d051-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/slave/test  
 Database Class Loader started - derby.database.classpath=''
 2008-01-29 11:52:40.308 GMT:
 Shutting down instance c013800d-0117-c563-d051-03bf6570
 
 
 2008-01-29 11:52:40.320 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance a816c00e-0117-c563-d051-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/slave/test  
 2008-01-29 11:52:40.814 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
 starting
 ERROR XRE08: Replication slave mode started successfully for database 'test'. 
 Connection refused because the database is in replication slave mode. 
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
   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:211)
   at 
 org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
   at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
 Cleanup action completed
 2008-01-29 11:52:40.816 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
 starting
 ERROR XRE08: Replication slave mode started successfully for database 'test'. 
 Connection refused because the database is in replication slave mode. 
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
   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:211)
   at 
 org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
   at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
   at

[jira] Commented: (DERBY-3361) Specifying a non-existant slaveHost for startSlave seemingly succeeds in starting slave mode.


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

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

I think that's a good suggestion, Øystein. Since the thread that boots store 
and starts replication functionality cannot contact SlaveDatabase [1], I think 
the best way to do this is to let the client thread pull the information from 
the SlaveController.

An implication of this solution is, of course, that the connection attempt 
trying to start the slave will hang until the master has been started. I think 
that will be acceptable.

[1] Until the client thread leaves SlaveDatabase#boot, the Database service 
cannot be found by calling Monitor.findService

 Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
 starting slave mode.
 -

 Key: DERBY-3361
 URL: https://issues.apache.org/jira/browse/DERBY-3361
 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: Jørgen Løland

 Specifying a non-existant slaveHost for startSlave seemingly succeeds in 
 starting slave mode.
 ---
  CONNECT 
 'jdbc:derby://atum11:/test;startSlave=true;slaveHost=noSuchHost;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. 
 Slave derby.log shows a NPE:
 --
 2008-01-29 11:52:40.050 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance c013800d-0117-c563-d051-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/slave/test  
 Database Class Loader started - derby.database.classpath=''
 2008-01-29 11:52:40.308 GMT:
 Shutting down instance c013800d-0117-c563-d051-03bf6570
 
 
 2008-01-29 11:52:40.320 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.4.0.0 alpha - (615841M): instance a816c00e-0117-c563-d051-03bf6570
 on database directory 
 /export/home/tmp/os136789/Replication_common_Trunk/slave/test  
 2008-01-29 11:52:40.814 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
 starting
 ERROR XRE08: Replication slave mode started successfully for database 'test'. 
 Connection refused because the database is in replication slave mode. 
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
   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:211)
   at 
 org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
   at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932)
   at 
 org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
 Cleanup action completed
 2008-01-29 11:52:40.816 GMT Thread[DRDAConnThread_2,5,main] Cleanup action 
 starting
 ERROR XRE08: Replication slave mode started successfully for database 'test'. 
 Connection refused because the database is in replication slave mode. 
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection30.init(EmbedConnection30.java:73)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection40.init(EmbedConnection40.java:54)
   at

Re: Request to add to developer list

2008-01-29 Thread Rick Hillegas


Vidyalakshmi wrote:

Sir

Please add my id  queen007  to Derby developers list.

Thanks  Regards
R Vidya Lakshmi
  

Hi Vidya,

I see that you have been added to the derby developer list already. 
Please let me know if you are having trouble.


Welcome!
-Rick

[jira] Resolved: (DERBY-3324) JDBC statement cache implementation

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

Kristian Waagan resolved DERBY-3324.

Resolution: Fixed
Derby Info: (was: [Patch Available])

Committed 'derby-3324-1e-jdbc_statementcache.diff' to trunk with revision
616373.
I'm marking the issue fixed, but I will not close it before the tests have been
enabled.
The issue might also be reopened if changes have to be made later in the
development process of the JDBC statement cache feature.

JDBC statement cache implementation
---

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

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-29 Thread Dyre Tjeldvoll (JIRA)


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

Dyre Tjeldvoll commented on DERBY-3301:
---

With the two patches I get a failure in lang/subqueryFlattening.sql. 
From a quick look at the diff it seems like the test dumps a query plan that 
is different with the patch. I guessing that the master file needs to be 
updated, 
but it would be nice if someone could confirm it.

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
Assignee: Thomas Nielsen
 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, 
 derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, 
 derby-3301-4c.diff, derby-3301-test-1.diff, derby-3301-test-1.stat, 
 derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, 
 derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY

[jira] Commented: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t


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

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

 I was looking at the spec at section 5.6.5.13 and if I read that correctly 
 (which perhaps I am not) we are limitted to 4 bytes for the locator. I am not 
 sure how to get around this hard limit.

I think you read it correctly (section 5.6.5 says bits 10-11 in lower box 
represent maximum length in bytes, not including length field or null 
indicator, and section 5.6.5.13 has the value 4 in bits 10-11). Note that with 
4 bytes we are limited to ~4 billion entries (or ~2 billion if the sign bit is 
stripped off), not 32K. It's just that the current implementation only uses two 
bytes, hence the 32K limit.

 (jdbc net client) exception during normal iteration through ResultSet of 
 select * from t
 

 Key: DERBY-3243
 URL: https://issues.apache.org/jira/browse/DERBY-3243
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.3.2.1
 Environment: -- Java Information --
 Java Version:1.4.2_03
 Java Vendor: Sun Microsystems Inc.
 Java home:   C:\Programme\Java\j2re1.4.2_03
 Java classpath:  derbyclient.jar
 OS name: Windows XP
 OS architecture: x86
 OS version:  5.1
 Java user name:  cbdqok
 Java user home:  C:\Dokumente und Einstellungen\cbdqok
 Java user dir:   D:\users\cbdqok\privat\osj\lib_derby_net\lib
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.4
 - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 - 
 (561794)
 --
 - Locale Information -
 --
Reporter: Oliver Seidel
Priority: Critical
 Attachments: derby-3243_fix_double_hashmap_entry_diff.txt, 
 derby-3243_fix_double_hashmap_entry_stat.txt


 Thanks again to the DERBY developers.
 For my convenience I use the client/server variant of DERBY.  This is where 
 the error occurs.  I have temporarily alleviated the problem for my case by 
 using the embedded version.
 I'm forced to use outlook and have built a program which siphons the messages 
 into a derby database (phase 1 -- table has two varchar fields and a clob).  
 When reading them back (phase 2 -- simple select of all records in no 
 particular order, all 3 attributes), it has developed an exception.  This is 
 a result of data volume.  I have reduced the problem to a single 
 demonstration program.
 This behaviour, and the fact that the error is not a DERBY Exception, but a 
 proper exception coming back from the JDBC call, leads me to the diagnosis 
 that it is a derby network client jdbc problem.
 The problem has been reproduced once by Bryan Pendleton: 
 http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
 I'll try to attach the code error.java; it can also be found on: 
 http://www.os1.net/error.java
 Please use as follows:
 javac -classpath derby.jar:derbynet.jar error.java
 java -cp .:derby.jar:derbynet.jar error
 It will create a directory test_db and fill it with approx 120mb data.
 Then you will observe the failure. 
 /* -*- Mode:Java; c-basic-offset:8 -*- */
 // 
 
 public class error {
   // 
 
   public static final int port = 1527;
   public static final String host = 127.0.0.1;
   // 
 
   public static void log(String x) { System.out.println(x); };
   // 
 
   public static void log_stacktrace(Exception e) {
 java.io.StringWriter sw = new java.io.StringWriter();
 java.io.PrintWriter pw = new java.io.PrintWriter(sw);
 e.printStackTrace(pw);
 log(sw.toString());
   };
   // 
 
   public static void start_server() {
   try {
   org.apache.derby.drda.NetworkServerControl server =
   new 
 org.apache.derby.drda.NetworkServerControl(java.net.InetAddress.getByName(host),port);
   server.start(null);
   try { java.lang.Thread.sleep(5000); } catch (Exception 
 e) { };
   log(started DERBY on host +host+

[jira] Commented: (DERBY-3324) JDBC statement cache implementation


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

Daniel John Debrunner commented on DERBY-3324:
--

The order of the arguments of holdability, result set type  concurrency in the 
statement key objects are inconsistent.

E.g. StatementKeyFactory.newPrepared has:
   int holdability, int rst, int rsc

but it calls new StatementKey() with the order of:

   rst, rsc, holdability


and I think will be called from Connection.prepareStatement which has the order 
of:

 int resultSetType, int resultSetConcurrency, int resultSetHoldability


Since these are all int values the compiler will not help in ensuring that the 
arguments are passed correctly. I think this switching of arguments serves no 
purpose and has a high probability of generating bugs. Can the ordering be made 
consistent?


 JDBC statement cache implementation
 ---

 Key: DERBY-3324
 URL: https://issues.apache.org/jira/browse/DERBY-3324
 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-3324-1a-jdbc_statementcache.diff, 
 derby-3324-1a-jdbc_statementcache.stat, 
 derby-3324-1b-jdbc_statementcache.diff, 
 derby-3324-1b-jdbc_statementcache.stat, 
 derby-3324-1c-jdbc_statementcache.diff, 
 derby-3324-1c-jdbc_statementcache.stat, 
 derby-3324-1d-jdbc_statementcache.diff, derby-3324-1e-jdbc_statementcache.diff


 Implement a cache for storing JDBC prepared statement objects.
 The cache will be responsible for holding free prepared statement objects 
 that can be reused, and also to throw away objects if the cache grows too big.
 All objects in the cache must belong to the same physical connection, but 
 they can be reused across logical connections obtained from a single physical 
 connection in a connection pool.
 This component is probably a candidate for code sharing between the client 
 and the embedded driver. Sharing will not  be part of this issue.

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

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

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

Daniel John Debrunner commented on DERBY-1387:
--

- added a check in FileMonitor for the presence of certain JMX classes
before allowing JMX to be enabled. A warning is printed to derby.log and
(if relevant) the Network Server console if JMX support is not available
but derby.system.jmx=true. This probably needs some polishing, at least
in the FileMonitor, where I've simply called report() with a hard-coded
String as parameter.

Why is this needed? Derby supports loading modules defined in
modules.properties and that has a mechanism to indicate that a module requires
a specific jvm or set of Java classes. Is there some reason a new mechanism is
being invented?

Add JMX extensions to Derby
---

Key: DERBY-1387
URL: https://issues.apache.org/jira/browse/DERBY-1387
Project: Derby
Issue Type: New Feature
Components: Services
Reporter: Sanket Sharma
Assignee: John H. Embretsen
Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff,
DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff,
DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip,
DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat,
derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, Requirements for JMX
Updated.html, Requirements for JMX.html, Requirements for JMX.zip

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

[jira] Commented: (DERBY-3351) Implement a Pluggable Storage Engine Architecture in Derby

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

Daniel John Debrunner commented on DERBY-3351:
--

The monitor is an IoC container, but it's probably too specific to Derby to be
truly general purpose and probably more general purpose than Derby needs.

Modules.properties contains the list of modules that can be used by the system,
since it's the input to the monitor and the monitor can handle any module,
there is no requirement for the modules to be in the services.monitor package.
The monitor is code that manages the lifetime of modules in a Derby system.

Not sure what issue you are seeing with modules.properties being hard-coded,
it's the defined way that modules make themselves known to the system. There
can actually be multiple modules.properties, each with the same name but a
different location, typically as a resource in a jar file.

The mapping of format identifiers to instances may make more sense in the
services.io package. The only issue would be ensuring that when the monitor
(derby's system) is shutdown that any cached mapping of format identifier to
class is cleaned up. That's the only portion that is actually happening in the
monitor, and since the cache has the lifetime of the monitor it might make
sense to leave it there.

Implement a Pluggable Storage Engine Architecture in Derby
--

Key: DERBY-3351
URL: https://issues.apache.org/jira/browse/DERBY-3351
Project: Derby
Issue Type: New Feature
Components: Services, SQL, Store
Reporter: Dibyendu Majumdar
Assignee: Dibyendu Majumdar

My aim is to create a pluggable storage engine architecture for Derby, so
that the default store implementation can be replaced with alternative
storage engines. I have created my own storage engine which I would like to
use with Derby's SQL layer, so that is a motivation. But I also think that
this will benefit the community, and could lead to a pluggable storage engine
architecture similar to that of MySQL.
I am not yet sure where the storage engine boundary should lie. I would
welcome input in this area.

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

[jira] Created: (DERBY-3362) ControlRow NPE

ControlRow NPE
--

 Key: DERBY-3362
 URL: https://issues.apache.org/jira/browse/DERBY-3362
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.2.1
Reporter: James Alan Shepherd


I have a NPE in Derby 10.3.2.1 (10.3.1.4 does not show this behaviour) that is 
probably the same one discussed in DERBY-3216

FATAL 38406 [Main] (Start.java:153) - Start FAILED
org.springframework.transaction.TransactionSystemException: Could not commit 
JDBC transaction; nested exception is java.sql.SQLException: Java exception: ': 
java.lang.NullPointerException'.
Caused by:
java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.javaException(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.EmbedConnection.commit(Unknown Source)
at 
org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:238)
at 
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199)
at 
org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:245)
at 
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:651)
at 
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:621)
at 
org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:146)
at com.aaa.bbb.cccFactory$ddd.add(cccFactory.java:324)
at com.aaa.eee.fff.ggg.reload(ggg.java:44)
at com.aaa.eee.fff.ggg.startup(ggg.java:57)
at com.aaa.eee.fff.Start.startupEee(Start.java:170)
at com.aaa.eee.fff.Start.startup(Start.java:146)
at com.aaa.start.Starter.startup(Starter.java:264)
at com.aaa.start.Main.startup(Main.java:270)
at com.aaa.start.Main.main(Main.java:199)
Caused by: java.sql.SQLException: Java exception: ': 
java.lang.NullPointerException'.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
 Source)
... 21 more
Caused by: java.lang.NullPointerException
at 
org.apache.derby.impl.store.access.btree.ControlRow.getControlRowForPage(Unknown
 Source)
at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown 
Source)
at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown 
Source)
at 
org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(Unknown
 Source)
at 
org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(Unknown 
Source)
at org.apache.derby.impl.store.raw.xact.Xact.postTermination(Unknown 
Source)
at org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Unknown 
Source)
at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown 
Source)
at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown
 Source)
at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown
 Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(Unknown 
Source)
... 15 more

and derby.log:

2008-01-28 08:26:36.148 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), 
(DATABASE = directory:myDB), (DRDAID = null), Executing prepared statement: 
SELECT COUNT(*) FROM ZZZ WHERE nID IS NULL :End prepared statement
2008-01-28 08:26:36.150 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), 
(DATABASE = directory:myDB), (DRDAID = null), Committing
2008-01-28 08:26:36.188 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), 
(DATABASE = directory:myDB), (DRDAID = null), Cleanup action starting
2008-01-28 08:26:36.188 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), 
(DATABASE = directory:myDB), (DRDAID = null), Failed Statement is: null with 2 
parameters begin parameter #1: 1 :end parameter begin parameter #2: 1 :end param
eter
java.lang.NullPointerException
at 
org.apache.derby.impl.store.access.btree.ControlRow.getControlRowForPage(Unknown
 Source)
at

[jira] Commented: (DERBY-3351) Implement a Pluggable Storage Engine Architecture in Derby

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

Daniel John Debrunner commented on DERBY-3351:
--

Therefore, by default, it will try to always load these. In a situation where
the Store is replaced, or a different Store is used, this may not be
desirable.

No, that's not a problem. The monitor doesn't just load modules from
modules.properties and use them, it selects the module implementation that is
suitable for the given environment by:

- seeing what the current JDK level is and if a module implementation
supports it
- seeing what classes a module implementation requires and if they exist
- if the module implements ModuleSupportable and if so asking the module if
it can support the current environment.

As an example, modules.properties today contains three JDBC implementations,
JSR169, JDBC 3 and JDBC 4, having multiple exist is not an issue, the monitor
selects the correct one.

Implement a Pluggable Storage Engine Architecture in Derby
--

Key: DERBY-3351
URL: https://issues.apache.org/jira/browse/DERBY-3351
Project: Derby
Issue Type: New Feature
Components: Services, SQL, Store
Reporter: Dibyendu Majumdar
Assignee: Dibyendu Majumdar

--
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-3279) Derby 10.3.X ignores ORDER BY DESC when target column has an index and is used in an OR clause or an IN list.


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

abhala edited comment on DERBY-3279 at 1/29/08 1:25 PM:


cheese2.sql has test queries for patch d3279_v1.patch

  was (Author: abhala):
test queries for patch d3279_v1.patch
  
 Derby 10.3.X ignores ORDER BY DESC when target column has an index and is 
 used in an OR clause or an IN list.
 -

 Key: DERBY-3279
 URL: https://issues.apache.org/jira/browse/DERBY-3279
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1
 Environment: Rational Application Developer 7.0.0.2 (Eclipse 3.2.2), 
 J2RE 1.5.0 IBM J9 2.3 Windows XP
Reporter: Ajay Bhala
Assignee: A B
 Fix For: 10.4.0.0

 Attachments: cheese2.sql, d3279_v1.patch


 Running the following produces the error seen in Derby 10.3.X but not in 
 10.2.X nor in 10.1.X.
 Don't know if this related to DERBY-3231.
 First query is incorrectly sorted whereas the second one is okay when there 
 is an index on the table. 
 If the table is not indexed, the sort works correctly in DESC order.
 --
 create table CHEESE (
   CHEESE_CODE   VARCHAR(5),
   CHEESE_NAME   VARCHAR(20),
   CHEESE_COST   DECIMAL(7,4)
 );
 create index cheese_index on CHEESE (CHEESE_CODE DESC, CHEESE_NAME DESC, 
 CHEESE_COST DESC);
 INSERT INTO CHEESE (
   CHEESE_CODE,
   CHEESE_NAME,
   CHEESE_COST)
 VALUES ('0', 'GOUDA', 001.1234),
('0', 'EDAM', 002.),
('54321', 'EDAM', 008.5646),
('12345', 'GORGONZOLA', 888.2309),
('A', 'EDAM', 999.),
('54321', 'MUENSTER', 077.9545);
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='0' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='A' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;

-- 
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-3279) Derby 10.3.X ignores ORDER BY DESC when target column has an index and is used in an OR clause or an IN list.


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

abhala edited comment on DERBY-3279 at 1/29/08 1:26 PM:


AB, thank you for the patch file.  I patched the source from 10.3.2.1 with the 
file and re-ran my queries above.
All seems well.  However when I ran the queries in the attached file, I saw 
some incorrect sorting.  The queries are similar to the original posting save 
for the fact that CHEESE_COST is neither in the index nor in the ORDER BY 
clause.

  was (Author: abhala):
AB, thank you for the patch file.  I patched the source from 10.3.2.1 with 
the file and re-ran my queried above.
All seems well.  However when I ran the queries in the attached file, I saw 
some incorrect sorting.  The queries are similar to the original posting save 
for the fact that CHEESE_COST is neither in the index nor in the ORDER BY 
clause.
  
 Derby 10.3.X ignores ORDER BY DESC when target column has an index and is 
 used in an OR clause or an IN list.
 -

 Key: DERBY-3279
 URL: https://issues.apache.org/jira/browse/DERBY-3279
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1
 Environment: Rational Application Developer 7.0.0.2 (Eclipse 3.2.2), 
 J2RE 1.5.0 IBM J9 2.3 Windows XP
Reporter: Ajay Bhala
Assignee: A B
 Fix For: 10.4.0.0

 Attachments: cheese2.sql, d3279_v1.patch


 Running the following produces the error seen in Derby 10.3.X but not in 
 10.2.X nor in 10.1.X.
 Don't know if this related to DERBY-3231.
 First query is incorrectly sorted whereas the second one is okay when there 
 is an index on the table. 
 If the table is not indexed, the sort works correctly in DESC order.
 --
 create table CHEESE (
   CHEESE_CODE   VARCHAR(5),
   CHEESE_NAME   VARCHAR(20),
   CHEESE_COST   DECIMAL(7,4)
 );
 create index cheese_index on CHEESE (CHEESE_CODE DESC, CHEESE_NAME DESC, 
 CHEESE_COST DESC);
 INSERT INTO CHEESE (
   CHEESE_CODE,
   CHEESE_NAME,
   CHEESE_COST)
 VALUES ('0', 'GOUDA', 001.1234),
('0', 'EDAM', 002.),
('54321', 'EDAM', 008.5646),
('12345', 'GORGONZOLA', 888.2309),
('A', 'EDAM', 999.),
('54321', 'MUENSTER', 077.9545);
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='0' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='A' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;

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

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

Daniel John Debrunner commented on DERBY-2207:
--

Section 4.34.1.1 says the SQL-session role name is a property of the 
authorization stack and that is a property of the SQL-session context.

Section 10.4 says a routine invocation pushes a new  SQL-session context.

So I think the role still needs to be reverted when a routine is completed.

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Updated: (DERBY-3279) Derby 10.3.X ignores ORDER BY DESC when target column has an index and is used in an OR clause or an IN list.


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

Ajay Bhala updated DERBY-3279:
--

Attachment: cheese2.sql

test queries for patch d3279_v1.patch

 Derby 10.3.X ignores ORDER BY DESC when target column has an index and is 
 used in an OR clause or an IN list.
 -

 Key: DERBY-3279
 URL: https://issues.apache.org/jira/browse/DERBY-3279
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1
 Environment: Rational Application Developer 7.0.0.2 (Eclipse 3.2.2), 
 J2RE 1.5.0 IBM J9 2.3 Windows XP
Reporter: Ajay Bhala
Assignee: A B
 Fix For: 10.4.0.0

 Attachments: cheese2.sql, d3279_v1.patch


 Running the following produces the error seen in Derby 10.3.X but not in 
 10.2.X nor in 10.1.X.
 Don't know if this related to DERBY-3231.
 First query is incorrectly sorted whereas the second one is okay when there 
 is an index on the table. 
 If the table is not indexed, the sort works correctly in DESC order.
 --
 create table CHEESE (
   CHEESE_CODE   VARCHAR(5),
   CHEESE_NAME   VARCHAR(20),
   CHEESE_COST   DECIMAL(7,4)
 );
 create index cheese_index on CHEESE (CHEESE_CODE DESC, CHEESE_NAME DESC, 
 CHEESE_COST DESC);
 INSERT INTO CHEESE (
   CHEESE_CODE,
   CHEESE_NAME,
   CHEESE_COST)
 VALUES ('0', 'GOUDA', 001.1234),
('0', 'EDAM', 002.),
('54321', 'EDAM', 008.5646),
('12345', 'GORGONZOLA', 888.2309),
('A', 'EDAM', 999.),
('54321', 'MUENSTER', 077.9545);
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='0' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='A' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;

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

[jira] Commented: (DERBY-3279) Derby 10.3.X ignores ORDER BY DESC when target column has an index and is used in an OR clause or an IN list.


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

Ajay Bhala commented on DERBY-3279:
---

AB, thank you for the patch file.  I patched the source from 10.3.2.1 with the 
file and re-ran my queried above.
All seems well.  However when I ran the queries in the attached file, I saw 
some incorrect sorting.  The queries are similar to the original posting save 
for the fact that CHEESE_COST is neither in the index nor in the ORDER BY 
clause.

 Derby 10.3.X ignores ORDER BY DESC when target column has an index and is 
 used in an OR clause or an IN list.
 -

 Key: DERBY-3279
 URL: https://issues.apache.org/jira/browse/DERBY-3279
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1
 Environment: Rational Application Developer 7.0.0.2 (Eclipse 3.2.2), 
 J2RE 1.5.0 IBM J9 2.3 Windows XP
Reporter: Ajay Bhala
Assignee: A B
 Fix For: 10.4.0.0

 Attachments: cheese2.sql, d3279_v1.patch


 Running the following produces the error seen in Derby 10.3.X but not in 
 10.2.X nor in 10.1.X.
 Don't know if this related to DERBY-3231.
 First query is incorrectly sorted whereas the second one is okay when there 
 is an index on the table. 
 If the table is not indexed, the sort works correctly in DESC order.
 --
 create table CHEESE (
   CHEESE_CODE   VARCHAR(5),
   CHEESE_NAME   VARCHAR(20),
   CHEESE_COST   DECIMAL(7,4)
 );
 create index cheese_index on CHEESE (CHEESE_CODE DESC, CHEESE_NAME DESC, 
 CHEESE_COST DESC);
 INSERT INTO CHEESE (
   CHEESE_CODE,
   CHEESE_NAME,
   CHEESE_COST)
 VALUES ('0', 'GOUDA', 001.1234),
('0', 'EDAM', 002.),
('54321', 'EDAM', 008.5646),
('12345', 'GORGONZOLA', 888.2309),
('A', 'EDAM', 999.),
('54321', 'MUENSTER', 077.9545);
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='0' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='A' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;

-- 
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-01-29 Thread Rick Hillegas (JIRA)


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

Rick Hillegas commented on DERBY-2998:
--

Hi Thomas,

Thanks for the latest patch. I have applied it and can see that the following 
query runs correctly:

select *
from
(
  select row_number() over () as r, t.* from t
) tout
order by r;

but the following query generates an error:

select *
from
(
  select row_number() over () as r, t.* from t
) tout
where r  2;
ERROR XJ001: Java exception: 'ASSERT FAILED sourceResultSetNumber expected to 
be = 0 for null.R: org.apache.derby.shared.common.sanity.AssertFailure'.

But, of course, you already know this. What kind of feedback do you want on 
this patch? Thanks.

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


 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-2307) DatabaseMetaData.getTypeInfo nullability is incorrect for columns 1,7 and 9

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

Daniel John Debrunner commented on DERBY-2307:
--

Columns 7 9 have nullability that matches the SQL statement that produces
them after DERBY-3350 was fixed.

DatabaseMetaData.getTypeInfo nullability is incorrect for columns 1,7 and 9
---

Key: DERBY-2307
URL: https://issues.apache.org/jira/browse/DERBY-2307
Project: Derby
Issue Type: Bug
Components: JDBC, SQL
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
10.2.1.6, 10.2.2.0, 10.3.1.4
Reporter: Daniel John Debrunner
Priority: Minor

Columns TYPE_NAME, NULLABLE, SEARCHABLE are returned as nullable but should
not be. ODBC variant correctly makes these non-nullable.
From a quick look at the metadata query this may in fact be a language issue.
The query is based upon a VALUES clauses that has a list of literals that are
not NULL in these columns. Thus one would expect the implied type definition
to be not nullable. However some of the columns, e.g. 2 DATA_TYPE, have a
similar list of non-NULL literals are do appear as non-NULLABLE with
getTypeInfo. Not sure what leads to the different behaviour.
Look for comments in DatabaseMetaDataTest.testGetTypeInfo() with this bug
number for code t hat shows the issue.

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

[jira] Updated: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name


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

Bryan Pendleton updated DERBY-3355:
---

Derby Info: [Patch Available]

Suites.all and derbyall completed without errors. Please let me know of
any feedback on the patch proposal.

 Alter Column ... NULL ignores double quotes around column name
 --

 Key: DERBY-3355
 URL: https://issues.apache.org/jira/browse/DERBY-3355
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.1.4
 Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
 Attachments: patch.diff


 ' is not a column in the target table., SQL State: 42X04, Error Code: -1
 Hi:
 I think I have isolated a bug involving the use of double quotes to define a 
 column name. Here s the SQL to reproduce the bug, followed by the error 
 message generated by the final SQL statement. In order to make the bug go 
 away, eliminate all use of double quotes in the SQL statements below. Note 
 that the identical alter statement succeeds before the insert, and fail 
 after. I have spent a long time trying to isolate this problem, so please 
 take a look.
 CREATE TABLE Table2
 (
c VARCHAR(32672)
 );
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 INSERT INTO Table2(c) VALUES('yo');
 alter table Table2 ALTER COLUMN c NULL;
 alter table Table2 ALTER COLUMN c NOT NULL;
 Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012, 
 Building output: 0
 Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 1 Row(s) Inserted
 Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009, 
 Building output: 0
 Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003, 
 Building output: 0
 Error: java.sql.SQLException: Column 'C' is either not in any table in the 
 FROM list or appears within a join specification and is outside the scope of 
 the join specification or appears in a HAVING clause and is not in the GROUP 
 BY list. If this is a CREATE or ALTER TABLE  statement then 'C' is not a 
 column in the target table., SQL State: 42X04, Error Code: -1
 -Inline Message Follows-
 Geoff hendrey wrote:
  I think I have isolated a bug involving the use of double quotes to
  define a column name.
 Hi Geoff, I agree, that is definitely a bug. Your script reproduces
 the problem for me, on the current Derby trunk.
 It appears that AlterTableConstantAction.validateNotNullConstraint
 is internally generating and executing a statement of the form:
 select count(*) from tab where not (col is not null)
 The code which generates this SQL staement is not properly enclosing
 the column name in double quotes, as you noticed, so the compiler
 converts the column name to upper case, and gets the no-such-column error.
 Can you open a problem report in Jira so that we can track this down
 and get it fixed?
 http://db.apache.org/derby/DerbyBugGuidelines.html
 thanks,
 bryan

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

[jira] Updated: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t


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

Kathey Marsden updated DERBY-3243:
--

Attachment: derby-3243_fix_double_hashmap_entry_diff2.txt

Here is the patch to fix the double hashmap entries without resetting the lob 
key.  I plan to commit this tomorrow if I don't hear back.

Kathey



 (jdbc net client) exception during normal iteration through ResultSet of 
 select * from t
 

 Key: DERBY-3243
 URL: https://issues.apache.org/jira/browse/DERBY-3243
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.3.2.1
 Environment: -- Java Information --
 Java Version:1.4.2_03
 Java Vendor: Sun Microsystems Inc.
 Java home:   C:\Programme\Java\j2re1.4.2_03
 Java classpath:  derbyclient.jar
 OS name: Windows XP
 OS architecture: x86
 OS version:  5.1
 Java user name:  cbdqok
 Java user home:  C:\Dokumente und Einstellungen\cbdqok
 Java user dir:   D:\users\cbdqok\privat\osj\lib_derby_net\lib
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.4
 - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 - 
 (561794)
 --
 - Locale Information -
 --
Reporter: Oliver Seidel
Priority: Critical
 Attachments: derby-3243_fix_double_hashmap_entry_diff.txt, 
 derby-3243_fix_double_hashmap_entry_diff2.txt, 
 derby-3243_fix_double_hashmap_entry_stat.txt


 Thanks again to the DERBY developers.
 For my convenience I use the client/server variant of DERBY.  This is where 
 the error occurs.  I have temporarily alleviated the problem for my case by 
 using the embedded version.
 I'm forced to use outlook and have built a program which siphons the messages 
 into a derby database (phase 1 -- table has two varchar fields and a clob).  
 When reading them back (phase 2 -- simple select of all records in no 
 particular order, all 3 attributes), it has developed an exception.  This is 
 a result of data volume.  I have reduced the problem to a single 
 demonstration program.
 This behaviour, and the fact that the error is not a DERBY Exception, but a 
 proper exception coming back from the JDBC call, leads me to the diagnosis 
 that it is a derby network client jdbc problem.
 The problem has been reproduced once by Bryan Pendleton: 
 http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
 I'll try to attach the code error.java; it can also be found on: 
 http://www.os1.net/error.java
 Please use as follows:
 javac -classpath derby.jar:derbynet.jar error.java
 java -cp .:derby.jar:derbynet.jar error
 It will create a directory test_db and fill it with approx 120mb data.
 Then you will observe the failure. 
 /* -*- Mode:Java; c-basic-offset:8 -*- */
 // 
 
 public class error {
   // 
 
   public static final int port = 1527;
   public static final String host = 127.0.0.1;
   // 
 
   public static void log(String x) { System.out.println(x); };
   // 
 
   public static void log_stacktrace(Exception e) {
 java.io.StringWriter sw = new java.io.StringWriter();
 java.io.PrintWriter pw = new java.io.PrintWriter(sw);
 e.printStackTrace(pw);
 log(sw.toString());
   };
   // 
 
   public static void start_server() {
   try {
   org.apache.derby.drda.NetworkServerControl server =
   new 
 org.apache.derby.drda.NetworkServerControl(java.net.InetAddress.getByName(host),port);
   server.start(null);
   try { java.lang.Thread.sleep(5000); } catch (Exception 
 e) { };
   log(started DERBY on host +host+ port 
 +Integer.toString(port)+.);
   } catch (Exception e) {
   log_stacktrace(e);
   };
   };
   // 
 
   public static java.sql.Connection con()
   throws java.sql.SQLException, java.lang.ClassNotFoundException {

[jira] Commented: (DERBY-3324) JDBC statement cache implementation

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

Kristian Waagan commented on DERBY-3324:

Yes it can.
I think I put holdability first because some methods only specify the
holdability, and I chose to keep the factory methods consistent. This was maybe
not such a good idea.

Another thing one could do (additionally), is to add asserts to enforce valid
values for the various properties. This would only affect sane builds though.
Is it worth adding, or too much checking?

I'll make a patch tomorrow.

JDBC statement cache implementation
---

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

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-29 Thread Craig Russell (JIRA)


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

Craig Russell commented on DERBY-3301:
--

Here are more queries, just slightly modified from the original queries. I've 
done little editing of the queries to avoid introducing copy/paste errors. 

This one works:
SELECT UNBOUND_E.PERSONID FROM applicationidentity0.DEPARTMENTS THIS , 
applicationidentity0.PERSONS UNBOUND_E 
  WHERE EXISTS (
SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
  WHERE THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_E.PERSONID = 
THIS_EMPLOYEES_E.PERSONID AND THIS.ID = 2)

This fails, returns 5 rows where 7 are expected. The difference between this 
and the original query is that THIS.ID is also returned in the outer select:
SELECT THIS.ID,UNBOUND_E.PERSONID,UNBOUND_P.PROJID FROM 
applicationidentity0.DEPARTMENTS THIS , applicationidentity0.PERSONS UNBOUND_E 
, applicationidentity0.PROJECTS UNBOUND_P 
  WHERE EXISTS (
SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
  WHERE EXISTS (
SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
   AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
   AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
   AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID
))

This fails, returns 3 rows where 5 are expected. 
SELECT UNBOUND_E.PERSONID,UNBOUND_P.PROJID FROM 
applicationidentity0.DEPARTMENTS THIS , applicationidentity0.PERSONS UNBOUND_E 
, applicationidentity0.PROJECTS UNBOUND_P 
  WHERE EXISTS (
SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
  WHERE EXISTS (
SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
THIS_EMPLOYEES_E_PROJECTS_P 
  WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
THIS_EMPLOYEES_E.PERSONID 
  AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
  AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
  AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID 
  AND THIS.ID = 1))

This fails, returning 5 rows where 7 are expected.
SELECT UNBOUND_E.PERSONID,UNBOUND_P.PROJID FROM 
applicationidentity0.DEPARTMENTS THIS , applicationidentity0.PERSONS UNBOUND_E 
, applicationidentity0.PROJECTS UNBOUND_P 
  WHERE EXISTS (
SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
  WHERE EXISTS (
SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
THIS_EMPLOYEES_E_PROJECTS_P 
  WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
THIS_EMPLOYEES_E.PERSONID 
  AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
  AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
  AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID 
  AND THIS.COMPANYID = 1))



 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
Assignee: Thomas Nielsen
 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, 
 derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, 
 derby-3301-4c.diff, derby-3301-test-1.diff, derby-3301-test-1.stat, 
 derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, 
 derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows

[jira] Commented: (DERBY-2142) NullPointerException while using XAConnection/PooledConnection in a heavily contended multithreaded scenario


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

Kathey Marsden commented on DERBY-2142:
---

Hi Dan,

Thanks for the fixture.  Here is the revised comment, gleaned from the comments 
in this issue and my understanding of it.


//DERBY-2142-Null out the connection handle BEFORE notifying 
listeners.
//At time of the callback the PooledConnection must be 
//disassociated from its previous logical connection.
//If not, there is a risk that the Pooled
//Connection could be returned to the pool, ready for pickup by 
a 
//new thread. This new thread then might obtain a 
java.sql.Connection 
//whose reference might get assigned to the 
currentConnectionHandle 
//field, meanwhile the previous thread completes the close 
making 
//the newly assigned currentConnectionHandle null, resulting in 
an NPE.




 NullPointerException while using XAConnection/PooledConnection in a heavily 
 contended multithreaded scenario
 

 Key: DERBY-2142
 URL: https://issues.apache.org/jira/browse/DERBY-2142
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 
 10.2.1.6
 Environment: The issue can appear in any environment as the bug is in 
 the source code . The bug has been verified in Suse Linux env.
Reporter: Asif H. Shahid
Assignee: Kathey Marsden
 Attachments: derby-2142_diff.txt, derby-2142_diff2.txt, 
 derby-2142_diff3.txt, derby-2142_stat.txt


 We are using the Derby's Transactional DataSource  class ( 
 org.apache.derby.jdbc.EmbeddedXADataSource ) to create a pool of  
 XAConnections in our application.
 Whenever a thread in a JTA transaction requests for a SQLConnection , we 
 retrieve an XAConnection from the pool. From the XAConnection , we  register 
 the XAResource with the TransactionManager  return a java.sql.Connection to 
 the application. 
 A class implementing the ConnectionEventListener is registered with the 
 XAConnection to get callback  connectionClosed ( ) when the thead closes the 
 java.sql.Connection. In this callback,  we invoke XAResource.end  return the 
 XAConnection to our pool  so that other threads can use it.
 We have encountered NullPointerException  , when performing operation on 
 java.sql.Connection.
 The stacktrace is as follows
 at
 org.apache.derby.jdbc.XAStatementControl.init(XAStatementControl.java:71)
at
 org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:162)
at
 org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(Unknown
 Source)
at
 com.gemstone.gemfire.internal.datasource.ConnectionPoolingTest$1.run(ConnectionPoolingTest.java:174)
at java.lang.Thread.run(Thread.java:595)
 I have done some debugging on source code of  db-derby-10.2.1.6-src  have 
 following explanation of the bug  a suggested fix. However, I want to 
 confirm that it is genuinely a bug  not a problem in our understanding of 
 the Datasource spec behaviour.
 Reason for the bug:-
 The class EmbedPooledConnection.java   stores in the field 
 currentConnectionHandle ( of  class BrokeredConnection)  a reference of the 
 java.sql.Connection object , being returned to the application, 
 Now ,whenever the client closes the java.sql.Connection ,  the code flow is 
 EmbedPooledConnection.close() -- EmbedPooledConnection.notifyClose().
 In the function EmbedPooledConnection.notifyClose(), it notifies  my listener 
 ( javax.sql.ConnectionEventListener) ) where I return the XAConnection to the 
 pool ( after deregistering the XAResource). 
 The last line of EmbedPooledConnection.close()  makes the 
 currentConnectionHandle  field as null.
 The issue here is that  javax.sql.ConnectionEventListener.connectionClosed is 
 invoked before making the currentConenctionHandle field as null.  Thus 
 XAConnection is returned to the pool , ready for pickup by a new thread. This 
 new thread obtains a java.sql.Connection whose reference gets assigned to the 
 currentConnectionHandle field, meanwhile the previous thread completes the 
 EmbedPooledConnection.close  making the newly assigned 
 currentConnectionHandle as null.
 Thus a previous thread's close makes a field null of an XAConnection, which 
 has been assigned to a new thread.
 The bug is easily reproducible  in a multi threaded scenario ( 20 threads or 
 so) with a pool size of around 4 XAConnections so that there is heavy  
 contention on XAConnection. 
 The fix is to rearrange the code of EmbedPooledConenction.java 's

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

Daniel John Debrunner commented on DERBY-2207:
--

 I think the changing of the current role should invalidate the (activation 
 of) the prepared statement here, forcing a re-check at the second execute. 

Is this some new mechanism, because today prepared statements are invalidated, 
not activations?

I think invalidating the prepared statements is a bad plan. A SET ROLE will 
become a common operation, especially for routines. Having a routine execution 
invalidate any prepared statements will cause tremendous performance problems 
as all users executing the routine will be constantly invalidating each other's 
plans.

I agree dropping a role should perform the invalidations, but not resetting a 
role.

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

2008-01-29 Thread Rick Hillegas (JIRA)

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

Rick Hillegas commented on DERBY-1387:
--

Thanks for the new patch, John. A couple comments:

1) The informational/error messages which return to the user still need to be
localized. It's probably a good idea to get this out the way before you get too
deep into testing. See Bernt's response on October 8, 2007.

2) I was pleasantly surprised to see that when I run this under jdk1.4, the
security manager doesn't choke on the missing jmx permissions. I guess the vm
must be silently swallowing ClassNotFoundExceptions.

3) I'm looking forward to some basic tests which will show me how to model some
experiments. In particular, I want to see how this JMX-initiated shutdown plays
with the new permissions introduced by DERBY-2109.

Add JMX extensions to Derby
---

Key: DERBY-1387
URL: https://issues.apache.org/jira/browse/DERBY-1387
Project: Derby
Issue Type: New Feature
Components: Services
Reporter: Sanket Sharma
Assignee: John H. Embretsen
Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff,
DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff,
DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip,
DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat,
derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, Requirements for JMX
Updated.html, Requirements for JMX.html, Requirements for JMX.zip

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

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

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

 For connection pooling I think that the reset of a connection from Derby's 
 PooledConnection needs to reset the role to nothing. Is that being handled?

I have not handled this area yet, it sounds reasonable. Thanks for the reminder!

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

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

As for the setting of NONE, please also see the discussion here: 
https://issues.apache.org/jira/browse/DERBY-3137?focusedCommentId=12540465#action_12540465
I think I agree that your reading is correct, but it seems restrictive..

I also notice that the corrigendum also now states in 18.3 (my emphasis):

Set the *SQL-session role name* and the current role name for the current 
SQL-session context.

whereas previously it said:

Set the current role name for the current SQL-session context.

Does this mean that the role set inside a stored procedure should be in effect 
also after returning? Or is it just semantic
finery?

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Closed: (DERBY-3350) SQL CAST always marks its type as nullable even if the expression to be cast is not nullable


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

Daniel John Debrunner closed DERBY-3350.


   Resolution: Fixed
Fix Version/s: 10.4.0.0

Resolved with revision 616473 to trunk. Ensure that all changed nullability 
seen by tests was due to a CAST and the correct state was being returned.

 SQL CAST always marks its type as nullable even if the expression to be cast 
 is not nullable
 

 Key: DERBY-3350
 URL: https://issues.apache.org/jira/browse/DERBY-3350
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 
 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0
Reporter: Daniel John Debrunner
Assignee: Daniel John Debrunner
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: derby3350_code_diff.txt


 Can be exposed as a column's type in a ResultSet being nullable when in 
 reality it can never be null.
 Can impact performance as the SQL compiler can general optimal paths with 
 correct nullability, e.g. a non-null INTEGER expression does not need 
 normalization if being stored in a non-null INTEGER column, routine calling 
 can be optimized for a RETURNS NULL ON NULL INPUT function if the inputs are 
 never null.

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

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

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

John H. Embretsen commented on DERBY-1387:
--

Dan wrote:

Why is this needed? Derby supports loading modules defined in
modules.properties and that has a
mechanism to indicate that a module requires a specific jvm or set of Java
classes. Is there some
reason a new mechanism is being invented?

Well... kindof. The reason is that I tried using modules.properties for this
but my brief experiments had no effect. So there's probably a piece of the
module puzzle that I have missed, and it might be due to how the JMX module is
currently started - I'm not sure, since I didn't write most of this code, and I
would most likely need to spend quite some time with a debugger to understand
all the details. My goal was to get this up and running so I could start
writing tests for it, but if I get some helpful pointers I'll be happy to
change how this works.

Add JMX extensions to Derby
---

Key: DERBY-1387
URL: https://issues.apache.org/jira/browse/DERBY-1387
Project: Derby
Issue Type: New Feature
Components: Services
Reporter: Sanket Sharma
Assignee: John H. Embretsen
Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff,
DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff,
DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip,
DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat,
derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, Requirements for JMX
Updated.html, Requirements for JMX.html, Requirements for JMX.zip

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


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

James Alan Shepherd updated DERBY-3360:
---

  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)

  was:
Derby 10.3 Branch [10.3.2.2 - (616244M)]
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)

Affects Version/s: 10.3.2.1

 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

 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 = URID.h
 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:115)
 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.BinaryLogicalOperatorNode.generateExpression(BinaryLogicalOperatorNode.java:157)
 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.JoinNode.getJoinArguments(JoinNode.java:1579)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generateCore(JoinNode.java:1555)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generate(JoinNode.java:1479)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.getJoinArguments(JoinNode.java:1577)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generateCore(JoinNode.java:1555)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generate(JoinNode.java:1479)
 at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1440)
 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.EmbedPreparedStatement.init(EmbedPreparedStatement.java:129)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(EmbedPreparedStatement20.java:82)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(EmbedPreparedStatement30.java:63)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(EmbedPreparedStatement40.java:40)
 at 
 org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Driver40.java:105)
 at

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


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

James Alan Shepherd commented on DERBY-3360:


10.3.2.1 (sane) shows the behaviour.

Now, here's the rub:

10.3.2.1 (insane) runs more of the SQL script, but fails with seemingly the 
same stack trace, the top of which from derby.log is:

java.lang.NullPointerException
at 
org.apache.derby.impl.sql.compile.ResultColumn.columnTypeAndLengthMatch(Unknown 
Source)
at 
org.apache.derby.impl.sql.compile.ResultColumnList.columnTypesAndLengthsMatch(Unknown
 Source)
at 
org.apache.derby.impl.sql.compile.ResultSetNode.columnTypesAndLengthsMatch(Unknown
 Source)
at org.apache.derby.impl.sql.compile.UnionNode.addNewNodes(Unknown 
Source)
at 
org.apache.derby.impl.sql.compile.UnionNode.modifyAccessPaths(Unknown Source)
at 
org.apache.derby.impl.sql.compile.SingleChildResultSetNode.modifyAccessPaths(Unknown
 Source)
at 
org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
Source)
at 
org.apache.derby.impl.sql.compile.DMLModStatementNode.optimizeStatement(Unknown 
Source)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
 Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeBatchElement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeBatch(Unknown 
Source)

This second failure point is like

INSERT INTO t1 (c1)
SELECT c1 FROM t2
UNION
SELECT c1FROM t3.

The crucial point is that the UNION has a SMALLINT column in it. If I re-write 
as:

INSERT INTO t1 (c1)
SELECT CAST(V.c1 AS SMALLINT)
FROM (
SELECT c1 FROM t2
UNION
SELECT c1FROM t3
) AS V

no NPE



 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.2
 Environment: Derby 10.3 Branch [10.3.2.2 - (616244M)]
 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

 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 = URID.h
 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:115)
 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.BinaryLogicalOperatorNode.generateExpression(BinaryLogicalOperatorNode.java:157)
 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.JoinNode.getJoinArguments(JoinNode.java:1579)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generateCore(JoinNode.java:1555)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generate(JoinNode.java:1479)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.getJoinArguments(JoinNode.java:1577)
 at 
 org.apache.derby.impl.sql.compile.JoinNode.generateCore(JoinNode.java:1555)
 at

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

Daniel John Debrunner commented on DERBY-2207:
--

The SQL TECHNICAL CORRIGENDUM 1 section 18.3 changes the syntax rules for SET 
ROLE. My reading of it is that NONE can now only appear as a keyword, NONE as a 
value expression does not mean set the current role to nothing. Not sure what 
the code is doing at the moment, I couldn't see any processing for NONE.

For connection pooling I think that the reset of a connection from Derby's 
PooledConnection needs to reset the role to nothing. Is that being handled?

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

Daniel John Debrunner commented on DERBY-2207:
--

Another question around SET ROLE.

What happens to a connection's prepared statements that were prepared when a 
role was in effect and now the role is not in effect?

E.g.

SET ROLE PAYROLL_ADMIN

prepare statement P1 -- which requires role PAYROLL_ADMIN

execute P1

SET ROLE NONE

execute P1 -- what happens here?

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Commented: (DERBY-3279) Derby 10.3.X ignores ORDER BY DESC when target column has an index and is used in an OR clause or an IN list.

2008-01-29 Thread A B (JIRA)


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

A B commented on DERBY-3279:


Thanks for running the tests, Ajay.

The removal of CHEESE_COST from the index means that the index now has a subset 
of the columns from the base table.  That in turn means that we have to 
generate an IndexToBaseRowNode above the base table (which we won't do if the 
index and the base table have the same columns).  In my first patch I 
overlooked this fact and thus did not propagate the call to 
adjustForSortElimination() down to the base table beneath IndexToBaseRowNode.

To fix this I just had to add an appropriate call to IndexToBaseRowNode:

+   /**
+* @see ResultSetNode#adjustForSortElimination
+*/
+   void adjustForSortElimination(RequiredRowOrdering rowOrdering)
+   throws StandardException
+   {
+   source.adjustForSortElimination(rowOrdering);
+   }

and the queries in cheese2.sql now sort correctly.  I want to look a bit more 
to see if there are any other cases where intermediary nodes are added above 
FromBaseTable and thus need a similar change, and then I will post a follow-up 
patch with the corresponding changes.

Thanks again for running more tests and reporting back!

 Derby 10.3.X ignores ORDER BY DESC when target column has an index and is 
 used in an OR clause or an IN list.
 -

 Key: DERBY-3279
 URL: https://issues.apache.org/jira/browse/DERBY-3279
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1
 Environment: Rational Application Developer 7.0.0.2 (Eclipse 3.2.2), 
 J2RE 1.5.0 IBM J9 2.3 Windows XP
Reporter: Ajay Bhala
Assignee: A B
 Fix For: 10.4.0.0

 Attachments: cheese2.sql, d3279_v1.patch


 Running the following produces the error seen in Derby 10.3.X but not in 
 10.2.X nor in 10.1.X.
 Don't know if this related to DERBY-3231.
 First query is incorrectly sorted whereas the second one is okay when there 
 is an index on the table. 
 If the table is not indexed, the sort works correctly in DESC order.
 --
 create table CHEESE (
   CHEESE_CODE   VARCHAR(5),
   CHEESE_NAME   VARCHAR(20),
   CHEESE_COST   DECIMAL(7,4)
 );
 create index cheese_index on CHEESE (CHEESE_CODE DESC, CHEESE_NAME DESC, 
 CHEESE_COST DESC);
 INSERT INTO CHEESE (
   CHEESE_CODE,
   CHEESE_NAME,
   CHEESE_COST)
 VALUES ('0', 'GOUDA', 001.1234),
('0', 'EDAM', 002.),
('54321', 'EDAM', 008.5646),
('12345', 'GORGONZOLA', 888.2309),
('A', 'EDAM', 999.),
('54321', 'MUENSTER', 077.9545);
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='0' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
 SELECT * FROM CHEESE 
 WHERE (CHEESE_CODE='A' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
 ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;

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

[jira] Commented: (DERBY-3351) Implement a Pluggable Storage Engine Architecture in Derby

2008-01-29 Thread Dibyendu Majumdar (JIRA)


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

Dibyendu Majumdar commented on DERBY-3351:
--

I was troubled by the fact that the Monitor implementation looks for 
org/apache/derby/modules.properties in the classpath, and the module.properties 
file that is found contains modules that are a mix from Language level and 
Store level modules. Therefore, by default, it will try to always load these. 
In a situation where the Store is replaced, or a different Store is used, this 
may not be desirable. 

The references to the services.io package is problematic for similar reasons. A 
Store replacement may have its own method of managing serialization, so it 
would be better if the Monitor package was blind to the type of serialization 
mechanism used. One option is to have a common Class/Object registry that is 
used by both monitor and the io services, rather than creating a dependency 
between the two.

I have another question - the StorageFactoryService contains calls to java.io 
package as well as the storageFactory abstraction. Shouldn't all IO be 
delegated to storageFactory components? It seems that even if a memory based 
storageFactory is used, the StorageFactoryService will still require some file 
IO. 

Thank you for answering my questions. 

 Implement a Pluggable Storage Engine Architecture in Derby
 --

 Key: DERBY-3351
 URL: https://issues.apache.org/jira/browse/DERBY-3351
 Project: Derby
  Issue Type: New Feature
  Components: Services, SQL, Store
Reporter: Dibyendu Majumdar
Assignee: Dibyendu Majumdar

 My aim is to create a pluggable storage engine architecture for Derby, so 
 that the default store implementation can be replaced with alternative 
 storage engines. I have created my own storage engine which I would like to 
 use with Derby's SQL layer, so that is a motivation. But I also think that 
 this will benefit the community, and could lead to a pluggable storage engine 
 architecture similar to that of MySQL.
 I am not yet sure where the storage engine boundary should lie. I would 
 welcome input in this area.

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

[jira] Updated: (DERBY-3200) Developer's Guide: Add examples showing use of SQL authorization with user authentication

2008-01-29 Thread Kim Haase (JIRA)

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

Kim Haase updated DERBY-3200:
-

Attachment: AuthExampleClientSQLAuth2.java
AuthExampleClientSQLAuth1.java
rdevcsecuresqlauthembeddedex.dita

Sorry about the long delay getting back to this. I've created a topic for the
example that shows SQL authorization with the embedded driver.

I've run into a problem, though, with the client driver. I'm trying to do
something similar to the two programs shown in the topic
http://db.apache.org/derby/docs/dev/devguide/rdevcsecureclientexample.html. I
have two programs similar to the ones in that example, except that the first
one sets sqlAuthorization to true along with the other properties, and creates
a new user.

In the second program, AuthExampleClientSQLAuth2.java, a user with full access
tries to grant the new user select and insert privileges. However, when I run
this program, I get an inexplicable error indicating that sqlAuthorization
isn't set, although it is. (I put in a debugging routine to display the values
of the properties just before I attempt the grant.) Here's a snippet of the
output showing the error:

Trying to connect to
jdbc:derby://localhost:1527/authClientDB;user=mary;password=little7xylamb
Connected to database authClientDB
Created table accessibletbl
Value of accessibletbl/textcol is hello
Reporting property values:
Value of requireAuthentication is true
Value of sqlAuthorization is true
Value of defaultConnectionMode is null
Value of fullAccessUsers is sa,mary
Value of readOnlyAccessUsers is guest

---SQLException Caught---

SQLState: 42Z60
Severity: -1
Message: GRANT not allowed unless database property
derby.database.sqlAuthorization has value 'TRUE'.
java.sql.SQLSyntaxErrorException: GRANT not allowed unless database property
derby.database.sqlAuthorization has value 'TRUE'.
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.executeUpdate(Unknown Source)
at AuthExampleClientSQLAuth2.main(AuthExampleClientSQLAuth2.java:92)
Caused by: org.apache.derby.client.am.SqlException: GRANT not allowed unless
database property derby.database.sqlAuthorization has value 'TRUE'.
at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
at
org.apache.derby.client.am.Statement.completeExecuteImmediate(Unknown Source)

The result is that the new user has the default full access and is able to
delete a row from the table.

I can't figure out why Derby doesn't know that sqlAuthorization is on. What is
wrong with the program? Any suggestions appreciated ...

Developer's Guide: Add examples showing use of SQL authorization with user
authentication
-

Key: DERBY-3200
URL: https://issues.apache.org/jira/browse/DERBY-3200
Project: Derby
Issue Type: Improvement
Components: Documentation
Reporter: Kim Haase
Assignee: Kim Haase
Priority: Minor
Attachments: AuthExampleClientSQLAuth1.java,
AuthExampleClientSQLAuth2.java, AuthExampleEmbeddedSQLAuth.java,
rdevcsecuresqlauthembeddedex.dita

This is the followup to DERBY-1823 that Francois Orsini suggested.
I've been experimenting and reading the Developer's Guide section on SQL
authorization (User authorizations, cdevcsecure36595).
It appears that the only use of SQL authorization mode is to restrict user
access, not to expand it.
For example, if you set the default connection mode to noAccess, a user with
fullAccess can't grant any privileges to a user with noAccess. And presumably
if the default connection mode is readOnlyAccess, a user with fullAccess
can't grant any privileges beyond SELECT, which the user has anyway.
Only if the default connection mode is fullAccess is SQL authorization mode
meaningful. That means that a fullAccess user can use GRANT to restrict
another user's privileges on a particular database that the user owns.
I'm running into a problem at the end, though. At the beginning of the
program, as nobody in particular, I was able to create several users, some of
them with full access. But at the end of the program, it seems that even a
user with full access isn't allowed to turn off those database properties:
Message: User 'MARY' does not have execute permission on PROCEDURE
'SYSCS_UTIL'.'SYSCS_SET_DATABASE_PROPERTY'.
This seems a bit extreme. I know that with SQL authorization on, the ability
to read from or write to database objects is further restricted to the owner
of the database objects. But the ability to execute built-in system

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

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

Re: changing current role after a prepare of a statement.

I am working on code to register dependencies of prepared statements (or just 
the activation?)  as well as triggers, views and constraints, of one (or more) 
roles being depended on (for the authorization check to succeed), cf. 
discussion in DERBY-3223.

I think the changing of the current role (or dropping of a role which the ps 
depends on) should invalidate the (activation of) the prepared statement
here, forcing a re-check at the second execute.


 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

Regression Test Report - tinderbox_trunk16 616475 - Sun DBTG

2008-01-29 Thread Ole . Solberg

[Auto-generated mail]

*tinderbox_trunk16* 616475/2008-01-29 19:52:43 CET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
  SunOS-5.10_i86pc-i386
0273273 087.44% derbyall
F:1,E:6100039996 0   1076.20% 
org.apache.derbyTesting.functionTests.suites.All
  Details in  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-616475.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/616475_bySig.html
 
---

Changes in  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/616475.txt 

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

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles

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

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

Is this some new mechanism, because today prepared statements are
invalidated, not activations?

Yes, one I was contemplating..

I think invalidating the prepared statements is a bad plan. A SET ROLE
will become a common operation, especially for routines. Having a
routine execution invalidate any prepared statements will cause
tremendous performance problems as all users executing the routine
will be constantly invalidating each other's plans.

Yes, this was my worry too, which is why I considered invalidating
just the activation.

I agree dropping a role should perform the invalidations, but not
resetting a role.

This seems right for persistent objects (view, triggers, constraints),
but in the case of the prepared statement (your example), it seems to
me be the role should still be in place when the execute is performed?
(although not for every cursor access :)

If so, some kind of invalidation seems called for...?

We could just wave our hands and say the check is only performed on
the first execute of a ps (when the checks are done for the activation
as it is created) I guess. Maybe that is acceptable although not
strictly compliant? Or does your interpretation lead you to believe it *is*
compliant?

Improve usability of Derby's client/server security by implementing ANSI Roles
--

Key: DERBY-2207
URL: https://issues.apache.org/jira/browse/DERBY-2207
Project: Derby
Issue Type: New Feature
Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
Attachments: spec.html, spec.html, spec.html, spec.html, spec.html,
spec.html

Implementing ANSI Roles will make it easier to manage security for multi-user
applications with high user turnover.

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

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

Daniel John Debrunner commented on DERBY-2207:
--

I meant using the existing prepared statement invalidation was too heavy for 
SET ROLE.

Something is needed to ensure security is maintained and that one cannot 
execute a statement that requires role R if R is not the current role.

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Commented: (DERBY-3137) SQL roles: add catalog support

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

Daniel John Debrunner commented on DERBY-3137:
--

I think it would be unwise to vary from the standard here:

If NULL is disallowed as a role name in SET ROLE then Derby should follow that
rule, not use NULL to mean NONE, especially when the SQL standard was corrected
to not allow the value expression to resolve to the special meaning of NONE.

Also for the TRIM case, I can't see any benefit to deviating from the standard.

Making the code stricter (and follow the standard) is an easier path forwards,
than less strict and then having backwards compatibility issues if it's needed
later to strictly enforce the standard.

SQL roles: add catalog support
--

Key: DERBY-3137
URL: https://issues.apache.org/jira/browse/DERBY-3137
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-3137-2.diff, DERBY-3137-2.stat, DERBY-3137-2.txt,
DERBY-3137-uuid.diff, DERBY-3137-uuid.stat, DERBY-3137.diff, DERBY-3137.diff,
DERBY-3137.stat, DERBY-3137.txt

As a next step after adding support for the roles syntax, I intend to
make a patch which implements catalog support for roles,
cf. SYS.SYSROLES described in the specification (attached to
DERBY-2207). Also the patch should tie this support up to the parser
support, so the role statements can be executed. Any privileges
granted to roles would still have no effect at run-time.

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

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


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

Daniel John Debrunner commented on DERBY-2207:
--

Minor comment on the spec, the syntax section for SET ROLE says it supports a 
value specification or NONE.

However the text indicates it *also* supports an identifier, the syntax section 
should be updated to reflect what is planned.

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Commented: (DERBY-3137) SQL roles: add catalog support


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

Daniel John Debrunner commented on DERBY-3137:
--

In SpecialFunctionNode.java the data type for CURRENT_ROLE indicates it is not 
nullable, but I thought CURRENT_ROLE returned NULL if no role had been set?

 SQL roles: add catalog support
 --

 Key: DERBY-3137
 URL: https://issues.apache.org/jira/browse/DERBY-3137
 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-3137-2.diff, DERBY-3137-2.stat, DERBY-3137-2.txt, 
 DERBY-3137-uuid.diff, DERBY-3137-uuid.stat, DERBY-3137.diff, DERBY-3137.diff, 
 DERBY-3137.stat, DERBY-3137.txt


 As a next step after adding support for the roles syntax, I intend to
 make a patch which implements catalog support for roles,
 cf. SYS.SYSROLES described in the specification (attached to
 DERBY-2207). Also the patch should tie this support up to the parser
 support, so the role statements can be executed. Any privileges
 granted to roles would still have no effect at run-time.

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

Are SimpleApp.java and SimpleMobileApp.java missing package statements?

2008-01-29 Thread Bryan Pendleton


If I run ant all twice in a row in my environment, SimpleApp.java
and SimpleMobileApp.java are always re-compiled.

It seems like this may be because the directory structure of the
source code indicates that SimpleApp.java should be in package 'simple',
and SimpleMobileApp.java should be in package 'simplemobile', but
in fact neither .java file contains a package statement.

Do others experience this same behavior?

thanks,

bryan

[jira] Commented: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t


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

Kathey Marsden commented on DERBY-3243:
---

So we do send and receive a 4 byte int, but we have this check in the 
locator(int column) method of NetCursor which says the highest bit will be set 
if it is not a locator, but it is not the highest bit that we are checking, so 
we end up using only two bytes for our locator.
 
Perhaps in the case of lob value we are reading the extended length indicator 
which will be 0x800x.  I'm not sure if that's what's going on though.  I did 
try  against a 10.2 server to see if the check is necessary for sending lobs by 
value and found that indeed it is.

Removing the check in 10.4 and just returning the locator gets us through the 
repro.

It seems like maybe instead of this check we should be able to tell by the drda 
type whether we have a locator or a value.

 private int locator(int column)
{
int locator = get_INTEGER(column);
// If Lob value was sent instead of locator, highest bit will be set
// Zero is not a valid locator, it indicates a zero length value
if (((locator  0x8000) == 0x8000) || (locator == 0)) {
return Lob.INVALID_LOCATOR;
} else {
return locator;
}
}

 (jdbc net client) exception during normal iteration through ResultSet of 
 select * from t
 

 Key: DERBY-3243
 URL: https://issues.apache.org/jira/browse/DERBY-3243
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.3.2.1
 Environment: -- Java Information --
 Java Version:1.4.2_03
 Java Vendor: Sun Microsystems Inc.
 Java home:   C:\Programme\Java\j2re1.4.2_03
 Java classpath:  derbyclient.jar
 OS name: Windows XP
 OS architecture: x86
 OS version:  5.1
 Java user name:  cbdqok
 Java user home:  C:\Dokumente und Einstellungen\cbdqok
 Java user dir:   D:\users\cbdqok\privat\osj\lib_derby_net\lib
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.4
 - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 - 
 (561794)
 --
 - Locale Information -
 --
Reporter: Oliver Seidel
Priority: Critical
 Attachments: derby-3243_fix_double_hashmap_entry_diff.txt, 
 derby-3243_fix_double_hashmap_entry_diff2.txt, 
 derby-3243_fix_double_hashmap_entry_stat.txt


 Thanks again to the DERBY developers.
 For my convenience I use the client/server variant of DERBY.  This is where 
 the error occurs.  I have temporarily alleviated the problem for my case by 
 using the embedded version.
 I'm forced to use outlook and have built a program which siphons the messages 
 into a derby database (phase 1 -- table has two varchar fields and a clob).  
 When reading them back (phase 2 -- simple select of all records in no 
 particular order, all 3 attributes), it has developed an exception.  This is 
 a result of data volume.  I have reduced the problem to a single 
 demonstration program.
 This behaviour, and the fact that the error is not a DERBY Exception, but a 
 proper exception coming back from the JDBC call, leads me to the diagnosis 
 that it is a derby network client jdbc problem.
 The problem has been reproduced once by Bryan Pendleton: 
 http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
 I'll try to attach the code error.java; it can also be found on: 
 http://www.os1.net/error.java
 Please use as follows:
 javac -classpath derby.jar:derbynet.jar error.java
 java -cp .:derby.jar:derbynet.jar error
 It will create a directory test_db and fill it with approx 120mb data.
 Then you will observe the failure. 
 /* -*- Mode:Java; c-basic-offset:8 -*- */
 // 
 
 public class error {
   // 
 
   public static final int port = 1527;
   public static final String host = 127.0.0.1;
   // 
 
   public static void log(String x) { System.out.println(x); };
   // 
 
   public static void log_stacktrace(Exception e) {
 java.io.StringWriter sw = new java.io.StringWriter();
 java.io.PrintWriter pw = new java.io.PrintWriter(sw);

statementJdbc20.java is 0 bytes in size?

2008-01-29 Thread Bryan Pendleton


In my environment, there is a file

org/apache/derbyTesting/functionTests/tests/jdbcapi/statementJdbc20.java

which is 0 bytes in size.

Is this a problem with my sandbox? Or was this file supposed to
have been deleted?

The reason I noticed it is that ant all always tries to compile it,
but of course doesn't succeed in producing a .class file.

thanks,

bryan

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles