Re: Looking towards 10.4
[EMAIL PROTECTED] wrote: Unless someone else volunteers to replace Bernt, I am prepared to take over as the next release manager, but on the condition that we can delay feature freeze to the March 1st time frame, because I have quite a bit of work left on DERBY-3221 and DERBY-3192. Regardless of who will be the next release manager I think it would be good have a discussion on when the feature freeze should be. I encourage everyone who is working on new features to post the feature freeze date they would like to see. Dyre, thanks for volunteering as release manager. March 1st sounds good to me - we have quite a few things left on our replication todo-list. -- Jørgen Løland
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[
https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jørgen Løland updated DERBY-3184:
-
Attachment: derby-3184-2b.stat
derby-3184-2b.diff
Øystein,
Thanks for reviewing the patch. I have addressed all your comments. Notes on
the revised patch:
5:
AFAIK, inner classes don't have constructors, but I added a setParams method
that does the same. Hence, removed local_*
11:
The methods of the Database interface are used in two scenarios:
1) After getting a connection to the database. This is taken care of by
throwing an exception from setupConnection, and thereby never returning a
connection.
2) When the connection is established, i.e. in the constructor of
EmbedConnection. The only Database method used from EmbedConnection is
getAuthenticationService, which is handled in SlaveDatabase by throwing an
exception.
I think this should suffice.
12:
I made the storage factory of UpdateServiceProperties volatile.
UpdateServiceProperties is only used during boot of a database, so this should
not result in a noticeable performance degradation.
13:
I changed the sleep time to 500 millis. The previous setting was used for
testing and I forgot to change it back.
Patch 2b is ready for review
> Replication: Connection attempts to a database in slave mode must fail
> --
>
> Key: DERBY-3184
> URL: https://issues.apache.org/jira/browse/DERBY-3184
> Project: Derby
> Issue Type: Sub-task
> Components: Services
>Affects Versions: 10.4.0.0
>Reporter: Jørgen Løland
>Assignee: Jørgen Løland
> Attachments: derby-3184-1.diff, derby-3184-1.stat,
> derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff,
> derby-3184-2b.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.stat
>
>
> When a database 'X' is booted in slave mode, the call to
> Monitor.startPersistentService("X",...) will not complete because the call
> gets stuck in LogToFile#recover. This is intentional.
> For as long as startPersistentService is blocked, however, other threads that
> try to connect to 'X' (effectively calling Monitor.findService("X", ...))
> will also hang. This is unacceptable, and needs to raise an error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3254) Implement the replication failover functionality
[ https://issues.apache.org/jira/browse/DERBY-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557916#action_12557916 ] V.Narayanan commented on DERBY-3254: I am proceeding to remove the stopSlave method implementation I had added here to the stop issue which needs to be reopened to address the comments there, the slave issue seemed to me the better context to address this issue. > Implement the replication failover functionality > > > Key: DERBY-3254 > URL: https://issues.apache.org/jira/browse/DERBY-3254 > Project: Derby > Issue Type: Sub-task > Components: Replication >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: failover_impl_notforcommit.diff, > failover_impl_notforcommit.stat, failover_impl_v1.diff, failover_impl_v1.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3254) Implement the replication failover functionality
[ https://issues.apache.org/jira/browse/DERBY-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557915#action_12557915 ] V.Narayanan commented on DERBY-3254: I will change this patch to do the following 1) Master initiates failover by sending a failover message to the slave and waits for the acknowledgment from the slave. (Slave will send an acknowledgement if its attempt to failover succeeds.) 2) If the acknowledgment is received it proceeds with failover. 3) Otherwise it continues as master without doing anything. > Implement the replication failover functionality > > > Key: DERBY-3254 > URL: https://issues.apache.org/jira/browse/DERBY-3254 > Project: Derby > Issue Type: Sub-task > Components: Replication >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: failover_impl_notforcommit.diff, > failover_impl_notforcommit.stat, failover_impl_v1.diff, failover_impl_v1.stat > > -- 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-3302) NullPointerException during recovery of database with territory-based collation
[
https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557912#action_12557912
]
mamtas edited comment on DERBY-3302 at 1/10/08 10:10 PM:
--
The majority of getLocaleFinder calls are from dead national character datatype
code.
In addition, it is also called by existing code (ie the code before collation
feature was added) for date, time and timestamp. I am not sure if that can run
into problem during recovery.
One place that I find suspicious is the SQLChar.like(dvd, dvd) method line
number 1767. This code is executed for non-national/non-collation sensitive
character types ie for UCS_BASIC character types and the code looks as follows
// Make sure we fail for both varchar an nvarchar
// for multiple collation characters.
SQLChar escapeSQLChar = (SQLChar) escape;
int[] escapeIntArray = escapeSQLChar.getIntArray();
if (escapeIntArray != null && (escapeIntArray.length != 1))
{
throw
StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new
String (escapeSQLChar.getCharArray()));
}
So, it appears that we are trying to see if number of collation elements
associated with escape character is more than 1 and if yes, then we throw
exception. Seems like a code like above should be done for collation sensitive
character types and not for UCS_BASIC character types. Interestingly, nothing
like this is getting checked for national character datatypes. I entered jira
entry DERBY-3315 for this.
was (Author: mamtas):
The majority of getLocaleFinder calls are from dead national character
datatype code.
In addition, it is also called by existing code (ie the code before collation
feature was added) for date, time and timestamp. I am not sure if that can run
into problem during recovery.
One place that I find suspicious is the SQLChar.like(dvd, dvd) method line
number 1767. This code is executed for non-national/non-collation sensitive
character types ie for UCS_BASIC character types and the code looks as follows
// Make sure we fail for both varchar an nvarchar
// for multiple collation characters.
SQLChar escapeSQLChar = (SQLChar) escape;
int[] escapeIntArray = escapeSQLChar.getIntArray();
if (escapeIntArray != null && (escapeIntArray.length != 1))
{
throw
StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new
String (escapeSQLChar.getCharArray()));
}
So, it appears that we are trying to see if number of collation elements
associated with escape character is more than 1 and if yes, then we throw
exception. Seems like a code like above should be done for collation sensitive
character types and not for UCS_BASIC character types. Interestingly, nothing
like this is getting checked for national character datatypes. I will enter a
jira entry for this.
> NullPointerException during recovery of database with territory-based
> collation
> ---
>
> Key: DERBY-3302
> URL: https://issues.apache.org/jira/browse/DERBY-3302
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
>Reporter: Knut Anders Hatlen
>Assignee: Mamta A. Satoor
>Priority: Critical
> Fix For: 10.4.0.0
>
> Attachments: npe.sql
>
>
> When logical undo is performed on a database with territory-based collation,
> you may get a NullPointerException in SQLChar.getCollationKey() because
> SQLChar.getLocaleFinder() returns null.
> This bug was reported on derby-user:
> http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3315) Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?
Should UCS_BASIC character types have to look at collation elements when
dealing with escape character in the LIKE clause?
--
Key: DERBY-3315
URL: https://issues.apache.org/jira/browse/DERBY-3315
Project: Derby
Issue Type: Task
Components: JDBC
Affects Versions: 10.3.2.1, 10.3.1.4, 10.4.0.0
Reporter: Mamta A. Satoor
Code in SQLChar.like(dvd, dvd) method at line number 1767 is executed for
non-national/non-collation sensitive character types ie for UCS_BASIC character
types and the code looks as follows
// Make sure we fail for both varchar an nvarchar
// for multiple collation characters.
SQLChar escapeSQLChar = (SQLChar) escape;
int[] escapeIntArray = escapeSQLChar.getIntArray();
if (escapeIntArray != null && (escapeIntArray.length != 1))
{
throw
StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new
String (escapeSQLChar.getCharArray()));
}
It appears that we are trying to see if number of collation elements associated
with escape character is more than 1 and if yes, then we throw exception. Seems
like a code like above should be done for collation sensitive character types
and not for UCS_BASIC character types. Interestingly, nothing like this is
getting checked for national character datatypes.
This behavior was detected while working on DERBY-3302
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[
https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557912#action_12557912
]
Mamta A. Satoor commented on DERBY-3302:
The majority of getLocaleFinder calls are from dead national character datatype
code.
In addition, it is also called by existing code (ie the code before collation
feature was added) for date, time and timestamp. I am not sure if that can run
into problem during recovery.
One place that I find suspicious is the SQLChar.like(dvd, dvd) method line
number 1767. This code is executed for non-national/non-collation sensitive
character types ie for UCS_BASIC character types and the code looks as follows
// Make sure we fail for both varchar an nvarchar
// for multiple collation characters.
SQLChar escapeSQLChar = (SQLChar) escape;
int[] escapeIntArray = escapeSQLChar.getIntArray();
if (escapeIntArray != null && (escapeIntArray.length != 1))
{
throw
StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new
String (escapeSQLChar.getCharArray()));
}
So, it appears that we are trying to see if number of collation elements
associated with escape character is more than 1 and if yes, then we throw
exception. Seems like a code like above should be done for collation sensitive
character types and not for UCS_BASIC character types. Interestingly, nothing
like this is getting checked for national character datatypes. I will enter a
jira entry for this.
> NullPointerException during recovery of database with territory-based
> collation
> ---
>
> Key: DERBY-3302
> URL: https://issues.apache.org/jira/browse/DERBY-3302
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
>Reporter: Knut Anders Hatlen
>Assignee: Mamta A. Satoor
>Priority: Critical
> Fix For: 10.4.0.0
>
> Attachments: npe.sql
>
>
> When logical undo is performed on a database with territory-based collation,
> you may get a NullPointerException in SQLChar.getCollationKey() because
> SQLChar.getLocaleFinder() returns null.
> This bug was reported on derby-user:
> http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Leak in client if resultset not closed
If I run the program below with
java -Xmx32M RepeatStatement
I will get an OutOfMemory error in the client.
java -Xmx32M RepeatStatement
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at
org.apache.derby.client.am.Cursor.allocateCharBuffer(Cursor.java:1260)
at
org.apache.derby.client.net.NetStatementReply.parseSQLDTARDarray(NetStatementReply.java:1356)
at
org.apache.derby.client.net.NetStatementReply.parseQRYDSC(NetStatementReply.java:1207)
at
org.apache.derby.client.net.NetStatementReply.parseOpenQuery(NetStatementReply.java:479)
at
org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply(NetStatementReply.java:223)
at
org.apache.derby.client.net.NetStatementReply.readOpenQuery(NetStatementReply.java:64)
at
org.apache.derby.client.net.StatementReply.readOpenQuery(StatementReply.java:50)
at
org.apache.derby.client.net.NetStatement.readOpenQuery_(NetStatement.java:153)
at
org.apache.derby.client.am.Statement.readOpenQuery(Statement.java:1396)
at
org.apache.derby.client.am.Statement.flowExecute(Statement.java:2001)
at
org.apache.derby.client.am.Statement.executeQueryX(Statement.java:421)
at
org.apache.derby.client.am.Statement.executeQuery(Statement.java:406)
at RepeatStatement.testInsertAndSelect(RepeatStatement.java:31)
at RepeatStatement.main(RepeatStatement.java:10)
If I close the ResultSet or Statement it does not leak. I seem to
recall there being a leak when ResultSets wern't closed, but only on the
server, DERBY-1104. I think it is a new bug, but I am not 100% sure. I
will file a bug tomorrow unless I hear from someone that it is already
filed.
import java.sql.*;
public class RepeatStatement {
public static void main(String[] args) throws Exception{
Class.forName("org.apache.derby.jdbc.ClientDriver");
String url = "jdbc:derby://localhost/testdb;create=true";
Connection conn = DriverManager.getConnection(url);
for (int i = 1; i < 32000; i++)
testInsertAndSelect(conn);
}
public static void testInsertAndSelect(Connection conn) throws
SQLException
{
Statement s = conn.createStatement();
try {
s.executeUpdate("DROP TABLE TAB");
} catch (SQLException se)
{
//ignore table not found exception
}
s.executeUpdate("CREATE TABLE TAB (col1 varchar(32672))");
PreparedStatement ps = conn.prepareStatement("INSERT INTO TAB
VALUES(?)");
ps.setString(1,"hello");
ps.executeUpdate();
ps.setString(1,"hello");
ps.executeUpdate();
ResultSet rs = s.executeQuery("SELECT * from tab");
// drain the resultset
while (rs.next());
// If I don't explicitly close the resultset or
// statement, we get a leak.
//rs.close();
//s.close();
ps.close();
}
}
[jira] Commented: (DERBY-2733) ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1.
[ https://issues.apache.org/jira/browse/DERBY-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557848#action_12557848 ] Myrna van Lunteren commented on DERBY-2733: --- I think further changes to the behavior of ij/ij.dataSource can be addressed in a separate JIRA; this one specifically addresses the NPE when using EmbeddedSimpleDataSource... > ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1. > -- > > Key: DERBY-2733 > URL: https://issues.apache.org/jira/browse/DERBY-2733 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4 > Environment: windows xp; j9 -jcl:foun11 -version: > java version "J2ME Foundation Specification v1.1" > IBM J9 2.3 Windows XP x86-32 (JIT enabled) > J9VM - 20061023_08962_lHdSMR > JIT - 20060629_1804ifx1_r8 > GC - 200609_15 > JCL - 20061020_1321,foun11 > Licensed Materials - Property of IBM > J9 - VM for the Java(TM) platform, Version 2.3 > (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved > Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86) > JIT - 20060629_1804ifx1_r8 >Reporter: Myrna van Lunteren >Assignee: Myrna van Lunteren > Attachments: DERBY-2733-doc.diff, DERBY-2733-src.diff, > DERBY-2733.diff2, DERBY-2733_3.diff, DERBY-2733_doc_3.diff, > DERBY-2733_doc_4.diff, DERBY-2733_doc_5.diff, rtoolsijcomref22318.html, > rtoolsijproprefdatasource.html, rtoolsijproprefdatasource.html, > rtoolsijproprefdatasource.html, rtoolsijproprefdatasource.html > > > When starting ij - with, or without any derby.properties, ij first shows this: > --- > java.lang.reflect.InvocationTargetException > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:215) > at java.lang.reflect.Method.invoke(Method.java:272) > at > org.apache.derby.impl.tools.ij.util.getDataSourceConnection(util.java:426) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:516) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:585) > at > org.apache.derby.impl.tools.ij.ConnectionEnv.init(ConnectionEnv.java:64) > at > org.apache.derby.impl.tools.ij.utilMain.initFromEnvironment(utilMain.java:179) > at org.apache.derby.impl.tools.ij.Main.(Main.java:230) > at org.apache.derby.impl.tools.ij.Main.getMain(Main.java:193) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:178) > at org.apache.derby.impl.tools.ij.Main.main(Main.java:73) > at org.apache.derby.tools.ij.main(ij.java:67) > Caused by: java.lang.NullPointerException > at > org.apache.derby.jdbc.InternalDriver.embeddedDriverAcceptsURL(InternalDriver.java:116) > at > org.apache.derby.jdbc.InternalDriver.acceptsURL(InternalDriver.java:107) > at > org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:126) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:406) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:373) > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:213) > ... 11 more > ij version 10.3 > ij> > After that, ij does appear to start normal operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2733) ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1.
[ https://issues.apache.org/jira/browse/DERBY-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-2733: -- Attachment: DERBY-2733_doc_5.diff rtoolsijproprefdatasource.html rtoolsijcomref22318.html Another attempt at making the documentation reflect the current behavior. > ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1. > -- > > Key: DERBY-2733 > URL: https://issues.apache.org/jira/browse/DERBY-2733 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4 > Environment: windows xp; j9 -jcl:foun11 -version: > java version "J2ME Foundation Specification v1.1" > IBM J9 2.3 Windows XP x86-32 (JIT enabled) > J9VM - 20061023_08962_lHdSMR > JIT - 20060629_1804ifx1_r8 > GC - 200609_15 > JCL - 20061020_1321,foun11 > Licensed Materials - Property of IBM > J9 - VM for the Java(TM) platform, Version 2.3 > (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved > Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86) > JIT - 20060629_1804ifx1_r8 >Reporter: Myrna van Lunteren >Assignee: Myrna van Lunteren > Attachments: DERBY-2733-doc.diff, DERBY-2733-src.diff, > DERBY-2733.diff2, DERBY-2733_3.diff, DERBY-2733_doc_3.diff, > DERBY-2733_doc_4.diff, DERBY-2733_doc_5.diff, rtoolsijcomref22318.html, > rtoolsijproprefdatasource.html, rtoolsijproprefdatasource.html, > rtoolsijproprefdatasource.html, rtoolsijproprefdatasource.html > > > When starting ij - with, or without any derby.properties, ij first shows this: > --- > java.lang.reflect.InvocationTargetException > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:215) > at java.lang.reflect.Method.invoke(Method.java:272) > at > org.apache.derby.impl.tools.ij.util.getDataSourceConnection(util.java:426) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:516) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:585) > at > org.apache.derby.impl.tools.ij.ConnectionEnv.init(ConnectionEnv.java:64) > at > org.apache.derby.impl.tools.ij.utilMain.initFromEnvironment(utilMain.java:179) > at org.apache.derby.impl.tools.ij.Main.(Main.java:230) > at org.apache.derby.impl.tools.ij.Main.getMain(Main.java:193) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:178) > at org.apache.derby.impl.tools.ij.Main.main(Main.java:73) > at org.apache.derby.tools.ij.main(ij.java:67) > Caused by: java.lang.NullPointerException > at > org.apache.derby.jdbc.InternalDriver.embeddedDriverAcceptsURL(InternalDriver.java:116) > at > org.apache.derby.jdbc.InternalDriver.acceptsURL(InternalDriver.java:107) > at > org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:126) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:406) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:373) > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:213) > ... 11 more > ij version 10.3 > ij> > After that, ij does appear to start normal operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3304) Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable
[
https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557829#action_12557829
]
Dag H. Wanvik commented on DERBY-3304:
--
Tried this, but it is not sufficient, it seems..
BaseActivation.reset will close the result set even if holdability is true, cf.
this line:
if (!resultSetHoldability || !resultSet.returnsRows())
{
// would really like to check if it is open,
// this is as close as we can approximate that.
resultSet.close();
Since CallStatementResultSet extends NoRowsResultSetImpl, the call to
resultSet.returnsRows() returns false, so the second condition holds, and close
ensues. NoRowsResultSetImpl#returnsRows is final so CallStatementResultSet
can't really override it. I tried it though, by removing the final, but then I
get an assert error since EmbedStatement#executeStatement, which also calls
ResultSet#returnsRows will now try to create a result set (line 1249 in
EmbedStatement.java). Which is reasonable ;-)
Maybe the test in BaseActivation.reset can test for CallStatementResultSet? Not
OO, though..Thinking aloud, maybe a new interface method of ResultSet:
canReturnDynamicResultSet?
> Explicit commit inside a java procedure makes a dynamic result sets passed
> out unavailable
> --
>
> Key: DERBY-3304
> URL: https://issues.apache.org/jira/browse/DERBY-3304
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.4.0.0
>Reporter: Daniel John Debrunner
> Attachments: Main.java
>
>
> Repro (Main.java) that shows changed behavior after svn 602991
> (the patch committed for this issue). It seems a regression: (originally from
> Dag H. Wanvik attached to DERBY-1585)
> An explicit commit inside a stored procedure makes a dynamic result sets
> passed out unavailable, even if the commit is executed *prior* to the result
> set; as in the repro.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3313) JDBC client driver statement cache
[ https://issues.apache.org/jira/browse/DERBY-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557827#action_12557827 ] Kristian Waagan commented on DERBY-3313: Thanks for giving feedback on the overview Dan. I was not aware of what you state about the cache in the embedded driver, and this was useful information. I will clarify the wording in the overview, and also think about the possibility to share code between both drivers. Just out of curiosity, how much work do you think is saved/avoided by the current scheme when it comes to re-preparing a statement in the embedded driver? Are we talking about less then 10%, something like 50% or more than that? I'm just looking for an indication of how much can be gained from caching JDBC statement objects in the embedded driver. Right now I'm not convinced the code can be shared directly and easily. From what I have seen previously, entering the realm of code sharing between the two drivers can result in quite a lot more work. I will keep it in the back of my head though, and try to make the right choices happen if sharing seems feasible. > JDBC client driver statement cache > -- > > Key: DERBY-3313 > URL: https://issues.apache.org/jira/browse/DERBY-3313 > Project: Derby > Issue Type: New Feature > Components: JDBC, Network Client >Affects Versions: 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan > Fix For: 10.4.0.0 > > Attachments: JDBCClientStatementCacheOverview.txt > > > A statement cache in the JDBC client driver will help increase performance in > certain scenarios, for instance some multi-tier systems using connection > pooling. > Please consult the comments and documents attached to this issue for more > information. -- 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 610848 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 610848/2008-01-10 18:42:16 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 0272272 086.39% derbyall F:1,E:01014810147 0 1197.02% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-610848.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/610848_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/610848.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-2733) ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1.
[ https://issues.apache.org/jira/browse/DERBY-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557794#action_12557794 ] John H. Embretsen commented on DERBY-2733: -- Dan, You make a good point, but is there a requirement that ij MUST connect automatically to a database when ij.dataSource is set? If there is a DataSource which does not support the databaseName property, or if an ij user for some reason does not want to set it (must be an edge case...), I don't see why IJ should try to connect automatically to some (undefined) database (apart from backwards compatibility reasons). My proposal was to not connect automatically if the database name is not set - the user can always run the connect command in ij to connect to any given database using the specified datasource. > ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1. > -- > > Key: DERBY-2733 > URL: https://issues.apache.org/jira/browse/DERBY-2733 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4 > Environment: windows xp; j9 -jcl:foun11 -version: > java version "J2ME Foundation Specification v1.1" > IBM J9 2.3 Windows XP x86-32 (JIT enabled) > J9VM - 20061023_08962_lHdSMR > JIT - 20060629_1804ifx1_r8 > GC - 200609_15 > JCL - 20061020_1321,foun11 > Licensed Materials - Property of IBM > J9 - VM for the Java(TM) platform, Version 2.3 > (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved > Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86) > JIT - 20060629_1804ifx1_r8 >Reporter: Myrna van Lunteren >Assignee: Myrna van Lunteren > Attachments: DERBY-2733-doc.diff, DERBY-2733-src.diff, > DERBY-2733.diff2, DERBY-2733_3.diff, DERBY-2733_doc_3.diff, > DERBY-2733_doc_4.diff, rtoolsijproprefdatasource.html, > rtoolsijproprefdatasource.html, rtoolsijproprefdatasource.html > > > When starting ij - with, or without any derby.properties, ij first shows this: > --- > java.lang.reflect.InvocationTargetException > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:215) > at java.lang.reflect.Method.invoke(Method.java:272) > at > org.apache.derby.impl.tools.ij.util.getDataSourceConnection(util.java:426) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:516) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:585) > at > org.apache.derby.impl.tools.ij.ConnectionEnv.init(ConnectionEnv.java:64) > at > org.apache.derby.impl.tools.ij.utilMain.initFromEnvironment(utilMain.java:179) > at org.apache.derby.impl.tools.ij.Main.(Main.java:230) > at org.apache.derby.impl.tools.ij.Main.getMain(Main.java:193) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:178) > at org.apache.derby.impl.tools.ij.Main.main(Main.java:73) > at org.apache.derby.tools.ij.main(ij.java:67) > Caused by: java.lang.NullPointerException > at > org.apache.derby.jdbc.InternalDriver.embeddedDriverAcceptsURL(InternalDriver.java:116) > at > org.apache.derby.jdbc.InternalDriver.acceptsURL(InternalDriver.java:107) > at > org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:126) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:406) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:373) > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:213) > ... 11 more > ij version 10.3 > ij> > After that, ij does appear to start normal operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[
https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-3302:
--
Could you comment on the SQLChar case, ie. the non collation recovery path. In
that case is there something that
guarantees at recovery time that localeFinder won't be null and we will never
enter the code for the database
context?:
protected LocaleFinder getLocaleFinder()
{
// This is not very satisfactory, as it creates a dependency on
// the DatabaseContext. It's the best I could do on short notice,
// though. - Jeff
if (localeFinder == null)
{
DatabaseContext dc = (DatabaseContext) ContextService.getContext(Dat
baseContext.CONTEXT_ID);
if( dc != null)
localeFinder = dc.getDatabase();
}
return localeFinder;
}
> NullPointerException during recovery of database with territory-based
> collation
> ---
>
> Key: DERBY-3302
> URL: https://issues.apache.org/jira/browse/DERBY-3302
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
>Reporter: Knut Anders Hatlen
>Assignee: Mamta A. Satoor
>Priority: Critical
> Fix For: 10.4.0.0
>
> Attachments: npe.sql
>
>
> When logical undo is performed on a database with territory-based collation,
> you may get a NullPointerException in SQLChar.getCollationKey() because
> SQLChar.getLocaleFinder() returns null.
> This bug was reported on derby-user:
> http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3155) Support for SQL:2003 MERGE statement
[ https://issues.apache.org/jira/browse/DERBY-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557766#action_12557766 ] Denis Assanbaev (RD-Software GmbH) commented on DERBY-3155: --- I find this feature usefull for also for other cases: currently derby cannot provide an update using data from another table. UPDATE XXX t_u set (col1, col2, col3) = (select col_n1,col_n2,col_n3 from XXX t_n where t_n.id = t_u.id). CURRENT OF- version doesn't help too. UPDATE XXX t_u set col1 = (select col_n1 from XXX t_n where t_n.id = t_u.id), col2 = (select col_n2 from XXX t_n where t_n.id = t_u.id). works, but it results in a lot of updates or performance boosts when using for a table with ~ 100 columns. Regards -- Mit freundlichen Grüßen / Kind Regards Denis > Support for SQL:2003 MERGE statement > > > Key: DERBY-3155 > URL: https://issues.apache.org/jira/browse/DERBY-3155 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Trejkaz > > A relatively common piece of logic in a database application is to check for > a row's existence and then either update or insert depending on its existence. > SQL:2003 added a MERGE statement to perform this operation. It looks like > this: > MERGE INTO table_name USING table_name ON (condition) > WHEN MATCHED THEN UPDATE SET column1 = value1 [, column2 = value2 ...] > WHEN NOT MATCHED THEN INSERT column1 [, column2 ...] VALUES (value1 [, > value2 ...]) > At the moment, the only workaround for this would be to write a stored > procedure to do the same operation, or to implement the logic client-side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2437) SYSCS_EXPORT_TABLE can be used to overwrite derby files
[ https://issues.apache.org/jira/browse/DERBY-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner closed DERBY-2437. > SYSCS_EXPORT_TABLE can be used to overwrite derby files > --- > > Key: DERBY-2437 > URL: https://issues.apache.org/jira/browse/DERBY-2437 > Project: Derby > Issue Type: Bug > Components: Security >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.4.0.0 >Reporter: Daniel John Debrunner >Priority: Critical > Fix For: 10.3.1.4, 10.4.0.0 > > > here are no controls over which files SYSCS_EXPORT_TABLE can write, thus > allowing any user that has permission to execute the procedure to try and > modufy information that they have no permissions to do. > In a similar fashion to the one described in DERBY-2436 I could overwrite > derby.properties at least leaqding to a dnial of service attack on the next > re-boot. > With more time it might be possible to write out a valid properties file > which would allow chaning the authentication, silentaly adding a new user etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3247) Activation for a dynamic ResultSet created from an Prepared/CallableStatement will not be closed until garbage collection indicates it is unused to the LCC and the LCC clos
[ https://issues.apache.org/jira/browse/DERBY-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner closed DERBY-3247. Resolution: Fixed Fix Version/s: 10.3.2.2 Revision: 610895 in 10.3 branch. > Activation for a dynamic ResultSet created from an Prepared/CallableStatement > will not be closed until garbage collection indicates it is unused to the LCC > and the LCC closes it > - > > Key: DERBY-3247 > URL: https://issues.apache.org/jira/browse/DERBY-3247 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.3.1.4, 10.4.0.0 >Reporter: Daniel John Debrunner >Assignee: Daniel John Debrunner >Priority: Minor > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: derby3247_diff.txt > > > In a Java procedure called from SQL any dynamic ResultSets that are created > using a PreparedStatement or CallableStatement leave their activations open > until : >- the statement that created it is garbage collected (which requires the > outer statement to be garbage collected) >- and the LCC processes unused Activations. > Dynamic ResultSets that are created by a Statement object are handled > correctly because they are marked single use activation and thus the close of > the ResultSet also closes the activation. > Fix is to mark the activation as single use in EmbedResultSet when the > EmbedResultSet is marked as being a dynamic ResultSet. This will then lead to > the close of the ResultSet also closing the activation. > Can't see how to write a test for this, I can see the activations stacking up > in a debugger, but typically there will be no visible user impact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-3247) Activation for a dynamic ResultSet created from an Prepared/CallableStatement will not be closed until garbage collection indicates it is unused to the LCC and the LCC cl
[ https://issues.apache.org/jira/browse/DERBY-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner reopened DERBY-3247: -- To marked fixed in 10.3 > Activation for a dynamic ResultSet created from an Prepared/CallableStatement > will not be closed until garbage collection indicates it is unused to the LCC > and the LCC closes it > - > > Key: DERBY-3247 > URL: https://issues.apache.org/jira/browse/DERBY-3247 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.3.1.4, 10.4.0.0 >Reporter: Daniel John Debrunner >Assignee: Daniel John Debrunner >Priority: Minor > Fix For: 10.4.0.0 > > Attachments: derby3247_diff.txt > > > In a Java procedure called from SQL any dynamic ResultSets that are created > using a PreparedStatement or CallableStatement leave their activations open > until : >- the statement that created it is garbage collected (which requires the > outer statement to be garbage collected) >- and the LCC processes unused Activations. > Dynamic ResultSets that are created by a Statement object are handled > correctly because they are marked single use activation and thus the close of > the ResultSet also closes the activation. > Fix is to mark the activation as single use in EmbedResultSet when the > EmbedResultSet is marked as being a dynamic ResultSet. This will then lead to > the close of the ResultSet also closing the activation. > Can't see how to write a test for this, I can see the activations stacking up > in a debugger, but typically there will be no visible user impact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
it looks like jira is not showing SVN links for committed work.
I checked a few issues in JIRA, like DERBY-3302. Commits to svn have happened but don't appear when you click on the svn tab. So don't count on the svn link tab to tell if a change has been committe or not right now. /mikem
[jira] Updated: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-3302: --- Fix Version/s: 10.4.0.0 > NullPointerException during recovery of database with territory-based > collation > --- > > Key: DERBY-3302 > URL: https://issues.apache.org/jira/browse/DERBY-3302 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Mamta A. Satoor >Priority: Critical > Fix For: 10.4.0.0 > > Attachments: npe.sql > > > When logical undo is performed on a database with territory-based collation, > you may get a NullPointerException in SQLChar.getCollationKey() because > SQLChar.getLocaleFinder() returns null. > This bug was reported on derby-user: > http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- 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-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557721#action_12557721 ] mamtas edited comment on DERBY-3302 at 1/10/08 11:23 AM: -- Commited a fix for this into trunk using revision 610846. I will work on merging this into 10.3 codeline and writing a test case. The tests ran fine on my Windows XP machine with Sun jdk1.4 The commit comments are as follows DERBY-3302 The user was running into null pointer exception at the time of database recovery because Derby was trying to get the Collator object through database context. But the Collator object is already available in the territory sensitive character classes and we do not have to go to database context to get it. I changed the code to use that collator object rather than look into database context. The reason for null pointer exception was that database context was not loaded yet during database recovery. was (Author: mamtas): Commited a fix for this into trunk using revision . I will work on merging this into 10.3 codeline and writing a test case. The tests ran fine on my Windows XP machine with Sun jdk1.4 The commit comments are as follows DERBY-3302 The user was running into null pointer exception at the time of database recovery because Derby was trying to get the Collator object through database context. But the Collator object is already available in the territory sensitive character classes and we do not have to go to database context to get it. I changed the code to use that collator object rather than look into database context. The reason for null pointer exception was that database context was not loaded yet during database recovery. > NullPointerException during recovery of database with territory-based > collation > --- > > Key: DERBY-3302 > URL: https://issues.apache.org/jira/browse/DERBY-3302 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: npe.sql > > > When logical undo is performed on a database with territory-based collation, > you may get a NullPointerException in SQLChar.getCollationKey() because > SQLChar.getLocaleFinder() returns null. > This bug was reported on derby-user: > http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557756#action_12557756 ] Mamta A. Satoor commented on DERBY-3302: Thanks for double-checking the fix, Knut. I am thinking of merging the fix into 10.3 tomorrow just to make sure that tests run fine on the tinderbox. All the tests ran fine on my machine. > NullPointerException during recovery of database with territory-based > collation > --- > > Key: DERBY-3302 > URL: https://issues.apache.org/jira/browse/DERBY-3302 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: npe.sql > > > When logical undo is performed on a database with territory-based collation, > you may get a NullPointerException in SQLChar.getCollationKey() because > SQLChar.getLocaleFinder() returns null. > This bug was reported on derby-user: > http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3312) Local Network Server Performance degradation with 10.2 or later
[ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3312: -- Component/s: Performance > Local Network Server Performance degradation with 10.2 or later > --- > > Key: DERBY-3312 > URL: https://issues.apache.org/jira/browse/DERBY-3312 > Project: Derby > Issue Type: Bug > Components: Network Server, Performance >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 > Environment: Intel x86 based server SuSE Linux Enterprise Server 10 > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Derby 10.3.2.1 >Reporter: Timothy Graf > > We have a Java based XML-RPC client/server product that incorporates an > embedded Derby database and network server. Our client uses the derby JDBC > ndriver and network client to connect to the Derby Network Server. > We recently moved from Cloudscape, which I believe used the 10.1.3.1 Derby > code, because of other issues which seem to be resolved by moving to the > latest Derby release. We have a very simple database with a simple table. > This table does include BLOBs, however its size has not been an issue and we > limit our records to 500. > Since moving to the latest release of Derby, version 10.3.2.1, we noticed > that our clients running on the same machine as our server take much longer > to retrieve a list of records from the database. Our clients running on a > remote machine do not seem to have any performance issues when retrieving the > same list of records. > We start our Network Server in Java through the API so I don't think the > Security Manager is the issue. I read that performance could be affected by > the Security Manager, but according to the Derby documentation, > "The Network Server will not attempt to install a security manager if you > start the server from your application using the programmatic API ..." > I tried going back several releases of Derby and the performance issue seems > to go away when I run with version 10.1.3.1 of Derby. However we see the > same issue that we saw with Cloudscape in that we can not turn off connection > logging. We also had stability problems with the Network Server with > Cloudscape. > We would really prefer to use the latest Derby release however the > performance issues are a sever limitation. I thought that maybe this was a > simple Network Server configuration issue however after researching this > issue I have not found anything from a configuration standpoint that may help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557751#action_12557751 ] Knut Anders Hatlen commented on DERBY-3302: --- Thanks for fixing this so quickly, Mamta! I have verified that the repro runs without failure with the fix. > NullPointerException during recovery of database with territory-based > collation > --- > > Key: DERBY-3302 > URL: https://issues.apache.org/jira/browse/DERBY-3302 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: npe.sql > > > When logical undo is performed on a database with territory-based collation, > you may get a NullPointerException in SQLChar.getCollationKey() because > SQLChar.getLocaleFinder() returns null. > This bug was reported on derby-user: > http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3314) RAND(SEED INTEGER) builtin function always returns the same random value for a given seed.
RAND(SEED INTEGER) builtin function always returns the same random value for a
given seed.
--
Key: DERBY-3314
URL: https://issues.apache.org/jira/browse/DERBY-3314
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.3.2.1, 10.3.1.4, 10.4.0.0
Reporter: Daniel John Debrunner
Priority: Minor
RAND or {fn RAND(seed)} exists to match the JDBC specification (section C.1)
RAND(integer) Random floating point for seed integer
Trouble is that Derby creates a new Random() instance for every call leading to
the same return value for the same seed. Seems to be useful, the function
should return a new random number even when handed the same seed.
Some more specification is probably needed, when does a sequence based upon a
seed start?
- first call by any connection
- sequence within a connection
- sequence within a sql context (e.g. procedure call, statement etc.)
Also need to be wary of memory leaks if the engine needs to hold onto Random
objects beyond the lifetime of the RAND call.
ij> values rand(3);
1
--
0.731057369148862
1 row selected
ij> values rand(3);
1
--
0.731057369148862
1 row selected
ij> values {fn rand(3)};
1
--
0.731057369148862
1 row selected
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3297) Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions.
[ https://issues.apache.org/jira/browse/DERBY-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557746#action_12557746 ] Daniel John Debrunner commented on DERBY-3297: -- Actually RAND is not a synonym for RANDOM. ij> values rand(); ERROR 42Y03: 'RAND' is not recognized as a function or procedure. RAND is a broken function that takes an INTEGER seed parameter. It's to match the JDBC escaped function spec but it's broken because it will always return the same value for a given seed. > Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. > -- > > Key: DERBY-3297 > URL: https://issues.apache.org/jira/browse/DERBY-3297 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Daniel John Debrunner >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d3297-doc-1.diff, d3297-doc-1.stat, d3297-doc-2.diff, > rreffunccosh.html, rreffunccot.html, rreffuncrand.html, rreffuncrandom.html, > rreffuncsign.html, rreffuncsinh.html, rreffunctanh.html, toc.html > > > These functions were added by DERBY-1808 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3297) Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions.
[ https://issues.apache.org/jira/browse/DERBY-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557741#action_12557741 ] Kim Haase commented on DERBY-3297: -- Thanks! The COSH fix is fine. For the RAND fix, it would be more consistent with the other similar functions if instead of The RAND function is a synonym for RANDOM. See (xref)RANDOM. the topic just said The RAND function is a synonym for (xref)RANDOM. I assume you will also be fixing RANDOM? > Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. > -- > > Key: DERBY-3297 > URL: https://issues.apache.org/jira/browse/DERBY-3297 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Daniel John Debrunner >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d3297-doc-1.diff, d3297-doc-1.stat, d3297-doc-2.diff, > rreffunccosh.html, rreffunccot.html, rreffuncrand.html, rreffuncrandom.html, > rreffuncsign.html, rreffuncsinh.html, rreffunctanh.html, toc.html > > > These functions were added by DERBY-1808 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Looking towards 10.4
[EMAIL PROTECTED] wrote: Unless someone else volunteers to replace Bernt, I am prepared to take over as the next release manager, but on the condition that we can delay feature freeze to the March 1st time frame, A release manager is all powerful, so if you want to be release manager you get to set your own date for the release. So thanks for offering and please do! Dan.
[jira] Commented: (DERBY-3313) JDBC client driver statement cache
[ https://issues.apache.org/jira/browse/DERBY-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557731#action_12557731 ] Daniel John Debrunner commented on DERBY-3313: -- Just to be clear, the overview says the embedded driver already has a statement cache, but I think it's a different type of cache. The embedded driver caches statement plans (not JDBC statement objects) that can be shared across multiple connections, I think you are planning to cache JDBC statement objects for a specific connection. If you are planning the latter then you may want to think about the fact that this would also be useful in an embedded environment, thus maybe the code could be made to work for both? Not a requirement, but something to think about. > JDBC client driver statement cache > -- > > Key: DERBY-3313 > URL: https://issues.apache.org/jira/browse/DERBY-3313 > Project: Derby > Issue Type: New Feature > Components: JDBC, Network Client >Affects Versions: 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan > Fix For: 10.4.0.0 > > Attachments: JDBCClientStatementCacheOverview.txt > > > A statement cache in the JDBC client driver will help increase performance in > certain scenarios, for instance some multi-tier systems using connection > pooling. > Please consult the comments and documents attached to this issue for more > information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Looking towards 10.4
Hi Everybody, According to http://wiki.apache.org/db-derby/DerbyTenFourRelease feature freeze for 10.4 i tomorrow! But I don't think that Bernt knew about (and took into consideration) the recent 10.3.2.1 update release when he wrote that. Normally I would expect Bernt to update this himself, but unfortunately he is currently not available to work on Derby and thereby prevented from being the release manager for 10.4. Unless someone else volunteers to replace Bernt, I am prepared to take over as the next release manager, but on the condition that we can delay feature freeze to the March 1st time frame, because I have quite a bit of work left on DERBY-3221 and DERBY-3192. Regardless of who will be the next release manager I think it would be good have a discussion on when the feature freeze should be. I encourage everyone who is working on new features to post the feature freeze date they would like to see. Thanks, -- Dyre Tjeldvoll
[jira] Commented: (DERBY-3297) Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions.
[ https://issues.apache.org/jira/browse/DERBY-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557726#action_12557726 ] Daniel John Debrunner commented on DERBY-3297: -- The SIGN function actually returns an INTEGER, -1, 0 or 1. > Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. > -- > > Key: DERBY-3297 > URL: https://issues.apache.org/jira/browse/DERBY-3297 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Daniel John Debrunner >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d3297-doc-1.diff, d3297-doc-1.stat, d3297-doc-2.diff, > rreffunccosh.html, rreffunccot.html, rreffuncrand.html, rreffuncrandom.html, > rreffuncsign.html, rreffuncsinh.html, rreffunctanh.html, toc.html > > > These functions were added by DERBY-1808 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557721#action_12557721 ] Mamta A. Satoor commented on DERBY-3302: Commited a fix for this into trunk using revision . I will work on merging this into 10.3 codeline and writing a test case. The tests ran fine on my Windows XP machine with Sun jdk1.4 The commit comments are as follows DERBY-3302 The user was running into null pointer exception at the time of database recovery because Derby was trying to get the Collator object through database context. But the Collator object is already available in the territory sensitive character classes and we do not have to go to database context to get it. I changed the code to use that collator object rather than look into database context. The reason for null pointer exception was that database context was not loaded yet during database recovery. > NullPointerException during recovery of database with territory-based > collation > --- > > Key: DERBY-3302 > URL: https://issues.apache.org/jira/browse/DERBY-3302 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: npe.sql > > > When logical undo is performed on a database with territory-based collation, > you may get a NullPointerException in SQLChar.getCollationKey() because > SQLChar.getLocaleFinder() returns null. > This bug was reported on derby-user: > http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Nested Call statements with dynamic result sets WAS Re: svn commit: r610184 - ...
Dag H. Wanvik wrote: [EMAIL PROTECTED] writes: Author: djd Date: Tue Jan 8 13:58:00 2008 New Revision: 610184 URL: http://svn.apache.org/viewvc?rev=610184&view=rev Log: Add additional test to ProcedureTest that tests a procedure call within a procedure call, the outer returning the dynamic result sets of the inner. Just curious here; I just read the Section 4.27.5 of the TECHNICAL CORRIGENDUM 1 to the SQL 2003 which describes what happens to dynamic result sets. I see this note: NOTE 48.3 -: Only the immediate invoker is considered. For example, if an externally-invoked procedure EIP executes a invoking an SQL-invoked procedure SIP3 that invokes SIP1, then the result set sequence returned by SIP1 is available only to SIP3, until either SIP3 returns control to EIP or another invocation of SIP1 by SIP3 is given before SIP3 returns. There is no mechanism whereby SIP3 can return SIP1's result set sequence to the invoker of SIP3, even if SIP3 is defined to be able to return a result set sequence. On the face of it it looks Derby allows this, but SQL prohibits it? This test seems to do what the last sentence says is not available, or maybe I missed something? H, it would seem that SQL prohibits this, that is a procedure returning the dynamic result sets of a procedure it calls. I wonder if it applies to SQL-invoked procedures implemented in Java though, the mechanism for returning a result set sequence is different in Java (See SQL part 13 section 8.3 GR) 18 & 19). From the JDBC level it's impossible to tell if a ResultSet comes from a CALL statement or any other statement since the api to obtain them is identical, that's not true in SQL. I guess the SQL engine (i.e. Derby) could keep internal state to track which result sets are dynamic and not allow them to be processed twice as dynamic ones. Just seems strange that returning a dynamic result from another SQL connection is implementation defined, whereas a valid dynamic result set from a nested CALL would be disallowed. It might be due to the fact that in SQL there is no mechanism to return such items, whereas in Java there can be a mechanism. Dan.
[jira] Updated: (DERBY-3312) Local Network Server Performance degradation with 10.2 or later
[ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner updated DERBY-3312: - Summary: Local Network Server Performance degradation with 10.2 or later (was: Local Network Server Performance) Clarify the summary to have some meaning. > Local Network Server Performance degradation with 10.2 or later > --- > > Key: DERBY-3312 > URL: https://issues.apache.org/jira/browse/DERBY-3312 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 > Environment: Intel x86 based server SuSE Linux Enterprise Server 10 > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Derby 10.3.2.1 >Reporter: Timothy Graf > > We have a Java based XML-RPC client/server product that incorporates an > embedded Derby database and network server. Our client uses the derby JDBC > ndriver and network client to connect to the Derby Network Server. > We recently moved from Cloudscape, which I believe used the 10.1.3.1 Derby > code, because of other issues which seem to be resolved by moving to the > latest Derby release. We have a very simple database with a simple table. > This table does include BLOBs, however its size has not been an issue and we > limit our records to 500. > Since moving to the latest release of Derby, version 10.3.2.1, we noticed > that our clients running on the same machine as our server take much longer > to retrieve a list of records from the database. Our clients running on a > remote machine do not seem to have any performance issues when retrieving the > same list of records. > We start our Network Server in Java through the API so I don't think the > Security Manager is the issue. I read that performance could be affected by > the Security Manager, but according to the Derby documentation, > "The Network Server will not attempt to install a security manager if you > start the server from your application using the programmatic API ..." > I tried going back several releases of Derby and the performance issue seems > to go away when I run with version 10.1.3.1 of Derby. However we see the > same issue that we saw with Cloudscape in that we can not turn off connection > logging. We also had stability problems with the Network Server with > Cloudscape. > We would really prefer to use the latest Derby release however the > performance issues are a sever limitation. I thought that maybe this was a > simple Network Server configuration issue however after researching this > issue I have not found anything from a configuration standpoint that may help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3297) Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions.
[ https://issues.apache.org/jira/browse/DERBY-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen updated DERBY-3297: -- Attachment: d3297-doc-2.diff rreffuncrand.html rreffunccosh.html Thanks for reviewing this Kim. Attaching updated patch d3297-doc-2.diff, and the two changed html pages; rreffunccosh.html and rreffuncrand.html. > Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. > -- > > Key: DERBY-3297 > URL: https://issues.apache.org/jira/browse/DERBY-3297 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Daniel John Debrunner >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d3297-doc-1.diff, d3297-doc-1.stat, d3297-doc-2.diff, > rreffunccosh.html, rreffunccot.html, rreffuncrand.html, rreffuncrandom.html, > rreffuncsign.html, rreffuncsinh.html, rreffunctanh.html, toc.html > > > These functions were added by DERBY-1808 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3297) Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions.
[ https://issues.apache.org/jira/browse/DERBY-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen updated DERBY-3297: -- Attachment: (was: rreffunccosh.html) > Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. > -- > > Key: DERBY-3297 > URL: https://issues.apache.org/jira/browse/DERBY-3297 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Daniel John Debrunner >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d3297-doc-1.diff, d3297-doc-1.stat, rreffunccot.html, > rreffuncrandom.html, rreffuncsign.html, rreffuncsinh.html, rreffunctanh.html, > toc.html > > > These functions were added by DERBY-1808 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3297) Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions.
[ https://issues.apache.org/jira/browse/DERBY-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen updated DERBY-3297: -- Attachment: (was: rreffuncrand.html) > Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. > -- > > Key: DERBY-3297 > URL: https://issues.apache.org/jira/browse/DERBY-3297 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Daniel John Debrunner >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d3297-doc-1.diff, d3297-doc-1.stat, rreffunccot.html, > rreffuncrandom.html, rreffuncsign.html, rreffuncsinh.html, rreffunctanh.html, > toc.html > > > These functions were added by DERBY-1808 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3312) Local Network Server Performance
[ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557696#action_12557696 ] Timothy Graf commented on DERBY-3312: - This is our create table command. CREATE TABLE INT_LOOKUPS( LKP_ID INTEGER GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), LKP_TYPE INTEGER, LKP_DATE DATE, PREV_LKP BLOB) >From one of our test servers here is the number of record and BLOB statistics. Number of records 497 Average BLOB size 2349 bytes Minimum BLOB size 1993 bytes Maximum BLOB size 2774 bytes > Local Network Server Performance > > > Key: DERBY-3312 > URL: https://issues.apache.org/jira/browse/DERBY-3312 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 > Environment: Intel x86 based server SuSE Linux Enterprise Server 10 > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Derby 10.3.2.1 >Reporter: Timothy Graf > > We have a Java based XML-RPC client/server product that incorporates an > embedded Derby database and network server. Our client uses the derby JDBC > ndriver and network client to connect to the Derby Network Server. > We recently moved from Cloudscape, which I believe used the 10.1.3.1 Derby > code, because of other issues which seem to be resolved by moving to the > latest Derby release. We have a very simple database with a simple table. > This table does include BLOBs, however its size has not been an issue and we > limit our records to 500. > Since moving to the latest release of Derby, version 10.3.2.1, we noticed > that our clients running on the same machine as our server take much longer > to retrieve a list of records from the database. Our clients running on a > remote machine do not seem to have any performance issues when retrieving the > same list of records. > We start our Network Server in Java through the API so I don't think the > Security Manager is the issue. I read that performance could be affected by > the Security Manager, but according to the Derby documentation, > "The Network Server will not attempt to install a security manager if you > start the server from your application using the programmatic API ..." > I tried going back several releases of Derby and the performance issue seems > to go away when I run with version 10.1.3.1 of Derby. However we see the > same issue that we saw with Cloudscape in that we can not turn off connection > logging. We also had stability problems with the Network Server with > Cloudscape. > We would really prefer to use the latest Derby release however the > performance issues are a sever limitation. I thought that maybe this was a > simple Network Server configuration issue however after researching this > issue I have not found anything from a configuration standpoint that may help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2733) ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1.
[ https://issues.apache.org/jira/browse/DERBY-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557693#action_12557693 ] Daniel John Debrunner commented on DERBY-2733: -- John> - I think it would be easier to use IJ with a datasource (and to document it) if IJ tries to connect automatically to a database ONLY IF ij.dataSource.databaseName is set. It makes no sense doing it otherwise. That's true with Derby but technically may not be true for all data source implementations. databaseName is a standard property for a data source but is not mandatory, so if ij remains a generic JDBC tool then there should not be a requirement for ij.dataSource.databaseName to be set. > ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1. > -- > > Key: DERBY-2733 > URL: https://issues.apache.org/jira/browse/DERBY-2733 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4 > Environment: windows xp; j9 -jcl:foun11 -version: > java version "J2ME Foundation Specification v1.1" > IBM J9 2.3 Windows XP x86-32 (JIT enabled) > J9VM - 20061023_08962_lHdSMR > JIT - 20060629_1804ifx1_r8 > GC - 200609_15 > JCL - 20061020_1321,foun11 > Licensed Materials - Property of IBM > J9 - VM for the Java(TM) platform, Version 2.3 > (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved > Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86) > JIT - 20060629_1804ifx1_r8 >Reporter: Myrna van Lunteren >Assignee: Myrna van Lunteren > Attachments: DERBY-2733-doc.diff, DERBY-2733-src.diff, > DERBY-2733.diff2, DERBY-2733_3.diff, DERBY-2733_doc_3.diff, > DERBY-2733_doc_4.diff, rtoolsijproprefdatasource.html, > rtoolsijproprefdatasource.html, rtoolsijproprefdatasource.html > > > When starting ij - with, or without any derby.properties, ij first shows this: > --- > java.lang.reflect.InvocationTargetException > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:215) > at java.lang.reflect.Method.invoke(Method.java:272) > at > org.apache.derby.impl.tools.ij.util.getDataSourceConnection(util.java:426) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:516) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:585) > at > org.apache.derby.impl.tools.ij.ConnectionEnv.init(ConnectionEnv.java:64) > at > org.apache.derby.impl.tools.ij.utilMain.initFromEnvironment(utilMain.java:179) > at org.apache.derby.impl.tools.ij.Main.(Main.java:230) > at org.apache.derby.impl.tools.ij.Main.getMain(Main.java:193) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:178) > at org.apache.derby.impl.tools.ij.Main.main(Main.java:73) > at org.apache.derby.tools.ij.main(ij.java:67) > Caused by: java.lang.NullPointerException > at > org.apache.derby.jdbc.InternalDriver.embeddedDriverAcceptsURL(InternalDriver.java:116) > at > org.apache.derby.jdbc.InternalDriver.acceptsURL(InternalDriver.java:107) > at > org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:126) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:406) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:373) > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:213) > ... 11 more > ij version 10.3 > ij> > After that, ij does appear to start normal operations. -- 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
Issue Subscription Filter: Derby: JIRA issues with patch available (17 issues) Subscriber: derby-dev Key Summary DERBY-3297 Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. https://issues.apache.org/jira/browse/DERBY-3297 DERBY-2733 ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1. https://issues.apache.org/jira/browse/DERBY-2733 DERBY-3309 Minor cleanups in ClientPooledConnection40 and ClientPooledConnection https://issues.apache.org/jira/browse/DERBY-3309 DERBY-3189 Replication: Add connection url command options for starting and stopping master https://issues.apache.org/jira/browse/DERBY-3189 DERBY-3311 Client ResultSet.getHoldabilty will return incorrect value when the ResultSet is obtained from a procedure call https://issues.apache.org/jira/browse/DERBY-3311 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-3184 Replication: Connection attempts to a database in slave mode must fail https://issues.apache.org/jira/browse/DERBY-3184 DERBY-3169 Add documentation for replication https://issues.apache.org/jira/browse/DERBY-3169 DERBY-3205 Replication: Add connection url command options for starting and stopping slave https://issues.apache.org/jira/browse/DERBY-3205 DERBY-3294 Convert demo/checkToursDB.java to junit https://issues.apache.org/jira/browse/DERBY-3294 DERBY-3254 Implement the replication failover functionality https://issues.apache.org/jira/browse/DERBY-3254 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-3023 Different result rows depending on the sequence of INNER JOIN and OUTER JOIN https://issues.apache.org/jira/browse/DERBY-3023 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] Commented: (DERBY-3312) Local Network Server Performance
[ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557689#action_12557689 ] Timothy Graf commented on DERBY-3312: - Yes, for our client retrieving records over the network is faster than one of our clients running on the same machine as our server. This symptom is only seen in versions 10.2.1.6 of Derby or higher. If I revert back to version 10.1.3.1 of Derby we do not see the difference in performance for a client run locally versus over the network. Our clients use JDBC to retrieve the entire list of records from our only table in the database and yes, we do limit the maximum number of records to 500. I'll reply again with the additional information you requested. Thanks very much for your reply. > Local Network Server Performance > > > Key: DERBY-3312 > URL: https://issues.apache.org/jira/browse/DERBY-3312 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 > Environment: Intel x86 based server SuSE Linux Enterprise Server 10 > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Derby 10.3.2.1 >Reporter: Timothy Graf > > We have a Java based XML-RPC client/server product that incorporates an > embedded Derby database and network server. Our client uses the derby JDBC > ndriver and network client to connect to the Derby Network Server. > We recently moved from Cloudscape, which I believe used the 10.1.3.1 Derby > code, because of other issues which seem to be resolved by moving to the > latest Derby release. We have a very simple database with a simple table. > This table does include BLOBs, however its size has not been an issue and we > limit our records to 500. > Since moving to the latest release of Derby, version 10.3.2.1, we noticed > that our clients running on the same machine as our server take much longer > to retrieve a list of records from the database. Our clients running on a > remote machine do not seem to have any performance issues when retrieving the > same list of records. > We start our Network Server in Java through the API so I don't think the > Security Manager is the issue. I read that performance could be affected by > the Security Manager, but according to the Derby documentation, > "The Network Server will not attempt to install a security manager if you > start the server from your application using the programmatic API ..." > I tried going back several releases of Derby and the performance issue seems > to go away when I run with version 10.1.3.1 of Derby. However we see the > same issue that we saw with Cloudscape in that we can not turn off connection > logging. We also had stability problems with the Network Server with > Cloudscape. > We would really prefer to use the latest Derby release however the > performance issues are a sever limitation. I thought that maybe this was a > simple Network Server configuration issue however after researching this > issue I have not found anything from a configuration standpoint that may help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3313) JDBC client driver statement cache
[ https://issues.apache.org/jira/browse/DERBY-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3313: --- Attachment: JDBCClientStatementCacheOverview.txt 'JDBCClientStatementCacheOverview.txt' (revision 1.0) gives a high level overview for a client side statement cache in Derby. I do plan to get this done for 10.4. Comments for the overview document is appreciated. > JDBC client driver statement cache > -- > > Key: DERBY-3313 > URL: https://issues.apache.org/jira/browse/DERBY-3313 > Project: Derby > Issue Type: New Feature > Components: JDBC, Network Client >Affects Versions: 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan > Fix For: 10.4.0.0 > > Attachments: JDBCClientStatementCacheOverview.txt > > > A statement cache in the JDBC client driver will help increase performance in > certain scenarios, for instance some multi-tier systems using connection > pooling. > Please consult the comments and documents attached to this issue for more > information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3313) JDBC client driver statement cache
JDBC client driver statement cache -- Key: DERBY-3313 URL: https://issues.apache.org/jira/browse/DERBY-3313 Project: Derby Issue Type: New Feature Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Fix For: 10.4.0.0 A statement cache in the JDBC client driver will help increase performance in certain scenarios, for instance some multi-tier systems using connection pooling. Please consult the comments and documents attached to this issue for more information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3297) Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions.
[ https://issues.apache.org/jira/browse/DERBY-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557676#action_12557676 ] Kim Haase commented on DERBY-3297: -- Thanks very much, Thomas -- these are excellent. Just a few minor items. COSH -- title is still "COS function". RAND -- I think we typically would just say "RAND is a synonym for RANDOM." (Compare CURRENT DATE, etc.) RANDOM -- in the first sentence, the verb should be "returns". I don't think you need the sentence "The data type of the returned value is a DOUBLE PRECISION number." -- that was already stated in the previous sentence. > Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. > -- > > Key: DERBY-3297 > URL: https://issues.apache.org/jira/browse/DERBY-3297 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Daniel John Debrunner >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d3297-doc-1.diff, d3297-doc-1.stat, rreffunccosh.html, > rreffunccot.html, rreffuncrand.html, rreffuncrandom.html, rreffuncsign.html, > rreffuncsinh.html, rreffunctanh.html, toc.html > > > These functions were added by DERBY-1808 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Zaun updated DERBY-2109: --- Attachment: (was: SystemPrivilegesTestCases.html) > System privileges > - > > Key: DERBY-2109 > URL: https://issues.apache.org/jira/browse/DERBY-2109 > Project: Derby > Issue Type: New Feature > Components: Security >Affects Versions: 10.3.1.4 >Reporter: Rick Hillegas >Assignee: Martin Zaun > Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, > derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, > DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, > DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, > SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, > systemPrivs.html, systemPrivs.html > > > Add mechanisms for controlling system-level privileges in Derby. See the > related email discussion at > http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. > The 10.2 GRANT/REVOKE work was a big step forward in making Derby more > secure in a client/server configuration. I'd like to plug more client/server > security holes in 10.3. In particular, I'd like to focus on authorization > issues which the ANSI spec doesn't address. > Here are the important issues which came out of the email discussion. > Missing privileges that are above the level of a single database: > - Create Database > - Shutdown all databases > - Shutdown System > Missing privileges specific to a particular database: > - Shutdown that Database > - Encrypt that database > - Upgrade database > - Create (in that Database) Java Plugins (currently Functions/Procedures, > but someday Aggregates and VTIs) > Note that 10.2 gave us GRANT/REVOKE control over the following > database-specific issues, via granting execute privilege to system > procedures: > Jar Handling > Backup Routines > Admin Routines > Import/Export > Property Handling > Check Table > In addition, since 10.0, the privilege of connecting to a database has been > controlled by two properties (derby.database.fullAccessUsers and > derby.database.defaultConnectionMode) as described in the security section of > the Developer's Guide (see > http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Zaun updated DERBY-2109: --- Attachment: SystemPrivilegesBehaviour.html DERBY-2109-08.diff DERBY-2109-08.stat Rick, thanks for your comments, I've incorporated 1), 2), and 3.a) and verified 3.b) and attached a new patch DERBY-2109-08 replacing DERBY-2109-07. I'd very much appreciate if you could give some scrutiny to the new document SystemPrivilegesBehaviour.html (replacing deleted SystemPrivilegesTestCases.html). Developers, with the latest patch DERBY-2109-08, I consider the work on System Privileges becoming ready for integration. By the specification of this feature, there will be some incompatibilities once integrated. For instance, users will have to provide credentials to "NetworkServerCommand shutdown" when running with authentication. Users with customized server.policy files will have to add a couple of permissions (when running with Authentication and SecurityManager). The user-visible changes with System Privileges and the error messages in case of failures are summarized and described by attached document SystemPrivilegesBehaviour.html. Please, have a close look and provide feedback. Thanks! Martin > System privileges > - > > Key: DERBY-2109 > URL: https://issues.apache.org/jira/browse/DERBY-2109 > Project: Derby > Issue Type: New Feature > Components: Security >Affects Versions: 10.3.1.4 >Reporter: Rick Hillegas >Assignee: Martin Zaun > Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, > derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, > DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, > DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, > SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, > systemPrivs.html, systemPrivs.html > > > Add mechanisms for controlling system-level privileges in Derby. See the > related email discussion at > http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. > The 10.2 GRANT/REVOKE work was a big step forward in making Derby more > secure in a client/server configuration. I'd like to plug more client/server > security holes in 10.3. In particular, I'd like to focus on authorization > issues which the ANSI spec doesn't address. > Here are the important issues which came out of the email discussion. > Missing privileges that are above the level of a single database: > - Create Database > - Shutdown all databases > - Shutdown System > Missing privileges specific to a particular database: > - Shutdown that Database > - Encrypt that database > - Upgrade database > - Create (in that Database) Java Plugins (currently Functions/Procedures, > but someday Aggregates and VTIs) > Note that 10.2 gave us GRANT/REVOKE control over the following > database-specific issues, via granting execute privilege to system > procedures: > Jar Handling > Backup Routines > Admin Routines > Import/Export > Property Handling > Check Table > In addition, since 10.0, the privilege of connecting to a database has been > controlled by two properties (derby.database.fullAccessUsers and > derby.database.defaultConnectionMode) as described in the security section of > the Developer's Guide (see > http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r610184 - /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java
[EMAIL PROTECTED] writes:
> Author: djd
> Date: Tue Jan 8 13:58:00 2008
> New Revision: 610184
>
> URL: http://svn.apache.org/viewvc?rev=610184&view=rev
> Log:
> Add additional test to ProcedureTest that tests a procedure call within a
> procedure call, the outer returning the dynamic result sets of the inner.
>
Just curious here; I just read the Section 4.27.5 of the TECHNICAL
CORRIGENDUM 1 to the SQL 2003 which describes what happens to dynamic
result sets. I see this note:
> NOTE 48.3 -: Only the immediate invoker is considered. For example, if
> an externally-invoked procedure EIP executes a
> invoking an SQL-invoked procedure SIP3 that invokes SIP1, then the
> result set sequence returned by SIP1 is available only to SIP3, until
> either SIP3 returns control to EIP or another invocation of SIP1 by
> SIP3 is given before SIP3 returns. There is no mechanism whereby SIP3
> can return SIP1's result set sequence to the invoker of SIP3, even if
> SIP3 is defined to be able to return a result set sequence.
On the face of it it looks Derby allows this, but SQL prohibits it?
This test seems to do what the last sentence says is not available, or
maybe I missed something?
> Modified:
>
> db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java
>
> Modified:
> db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java
> URL:
> http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java?rev=610184&r1=610183&r2=610184&view=diff
> ==
> ---
> db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java
> (original)
> +++
> db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java
> Tue Jan 8 13:58:00 2008
> @@ -729,7 +729,12 @@
>"CREATE PROCEDURE PROC_WITH_SIDE_EFFECTS(ret INT) LANGUAGE JAVA " +
>"PARAMETER STYLE JAVA EXTERNAL NAME '" +
>ProcedureTest.class.getName() + ".procWithSideEffects' " +
> - "DYNAMIC RESULT SETS 2"
> + "DYNAMIC RESULT SETS 2",
> +
> + "CREATE PROCEDURE NESTED_RESULT_SETS(proctext VARCHAR(128))
> LANGUAGE JAVA " +
> + "PARAMETER STYLE JAVA EXTERNAL NAME '" +
> + ProcedureTest.class.getName() + ".nestedDynamicResultSets' " +
> + "DYNAMIC RESULT SETS 6"
>
> };
>
> @@ -842,6 +847,43 @@
> }
> c.close();
> }
> +
> +/**
> + * Method for a Java procedure that calls another procedure
> + * and just passes on the dynamic results from that call.
> + */
> +public static void nestedDynamicResultSets(String procedureText,
> +ResultSet[] rs1, ResultSet[] rs2, ResultSet[] rs3, ResultSet[]
> rs4,
> +ResultSet[] rs5, ResultSet[] rs6)
> +throws SQLException
> +{
> +Connection c =
> DriverManager.getConnection("jdbc:default:connection");
> +
> +CallableStatement cs = c.prepareCall("CALL " + procedureText);
> +
> +cs.execute();
> +
> +// Mix up the order of the result sets in the returned
> +// parameters, ensures order is defined by creation
> +// and not parameter order.
> +rs6[0] = cs.getResultSet();
> +if (!cs.getMoreResults(Statement.KEEP_CURRENT_RESULT))
> +return;
> +rs3[0] = cs.getResultSet();
> +if (!cs.getMoreResults(Statement.KEEP_CURRENT_RESULT))
> +return;
> +rs4[0] = cs.getResultSet();
> +if (!cs.getMoreResults(Statement.KEEP_CURRENT_RESULT))
> +return;
> +rs2[0] = cs.getResultSet();
> +if (!cs.getMoreResults(Statement.KEEP_CURRENT_RESULT))
> +return;
> +rs1[0] = cs.getResultSet();
> +if (!cs.getMoreResults(Statement.KEEP_CURRENT_RESULT))
> +return;
> +rs5[0] = cs.getResultSet();
> +
> +}
>
>
> /**
> @@ -881,6 +923,14 @@
> java.util.Arrays.fill(allRS, null);
> checkCSCloseClosesResults(cs,allRS);
> java.util.Arrays.fill(allRS, null);
> +
[jira] Commented: (DERBY-2733) ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1.
[ https://issues.apache.org/jira/browse/DERBY-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557668#action_12557668 ] Kim Haase commented on DERBY-2733: -- Thanks for the fixes, Myrna! I think John's suggestions are excellent too. I was puzzling over that long sentence but could not think of a way to improve it. I was also thinking it would be good to have an example showing how to connect without specifying the protocol, but I thought if you got a stack trace that might not be practical. If it's just the one-line error I think the example is very helpful -- and even if there is a stack trace you could just have a line with an ellipsis (...) to indicate that. I'll leave it to you to decide whether to file a separate issue for the related fix to the connect command doc or to include it here. I think there would be no harm fixing it as part of this issue, since it's related. > ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1. > -- > > Key: DERBY-2733 > URL: https://issues.apache.org/jira/browse/DERBY-2733 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4 > Environment: windows xp; j9 -jcl:foun11 -version: > java version "J2ME Foundation Specification v1.1" > IBM J9 2.3 Windows XP x86-32 (JIT enabled) > J9VM - 20061023_08962_lHdSMR > JIT - 20060629_1804ifx1_r8 > GC - 200609_15 > JCL - 20061020_1321,foun11 > Licensed Materials - Property of IBM > J9 - VM for the Java(TM) platform, Version 2.3 > (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved > Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86) > JIT - 20060629_1804ifx1_r8 >Reporter: Myrna van Lunteren >Assignee: Myrna van Lunteren > Attachments: DERBY-2733-doc.diff, DERBY-2733-src.diff, > DERBY-2733.diff2, DERBY-2733_3.diff, DERBY-2733_doc_3.diff, > DERBY-2733_doc_4.diff, rtoolsijproprefdatasource.html, > rtoolsijproprefdatasource.html, rtoolsijproprefdatasource.html > > > When starting ij - with, or without any derby.properties, ij first shows this: > --- > java.lang.reflect.InvocationTargetException > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:215) > at java.lang.reflect.Method.invoke(Method.java:272) > at > org.apache.derby.impl.tools.ij.util.getDataSourceConnection(util.java:426) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:516) > at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:585) > at > org.apache.derby.impl.tools.ij.ConnectionEnv.init(ConnectionEnv.java:64) > at > org.apache.derby.impl.tools.ij.utilMain.initFromEnvironment(utilMain.java:179) > at org.apache.derby.impl.tools.ij.Main.(Main.java:230) > at org.apache.derby.impl.tools.ij.Main.getMain(Main.java:193) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:178) > at org.apache.derby.impl.tools.ij.Main.main(Main.java:73) > at org.apache.derby.tools.ij.main(ij.java:67) > Caused by: java.lang.NullPointerException > at > org.apache.derby.jdbc.InternalDriver.embeddedDriverAcceptsURL(InternalDriver.java:116) > at > org.apache.derby.jdbc.InternalDriver.acceptsURL(InternalDriver.java:107) > at > org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:126) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:406) > at > org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:373) > at > java.lang.reflect.AccessibleObject.invokeL(AccessibleObject.java:213) > ... 11 more > ij version 10.3 > ij> > After that, ij does appear to start normal operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3309) Minor cleanups in ClientPooledConnection40 and ClientPooledConnection
[ https://issues.apache.org/jira/browse/DERBY-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3309: --- Derby Info: [Patch Available] > Minor cleanups in ClientPooledConnection40 and ClientPooledConnection > - > > Key: DERBY-3309 > URL: https://issues.apache.org/jira/browse/DERBY-3309 > Project: Derby > Issue Type: Sub-task > Components: JDBC, Network Client >Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Trivial > Fix For: 10.2.2.1, 10.3.2.2, 10.4.0.0 > > Attachments: derby-3309-1a-unused_imports.diff, > derby-3309-2a-remove_unused_constructor.diff > > > A few minor cleanups: > 1) Remove unused constructor > 2) Remove unused imports > 3) Various documentation/formatting fixes > Other minor fixes will be done if required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3309) Minor cleanups in ClientPooledConnection40 and ClientPooledConnection
[ https://issues.apache.org/jira/browse/DERBY-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3309: --- Attachment: derby-3309-2a-remove_unused_constructor.diff 'derby-3309-2a-remove_unused_constructor.diff' removes an unused contructor in ClientPooledConnection and ClientPooledConnection40. I traced it back to when the client driver was donated/added, so I have no idea why it was once introduced. If anyone has information that indicates that it should not be removed, please let me know. > Minor cleanups in ClientPooledConnection40 and ClientPooledConnection > - > > Key: DERBY-3309 > URL: https://issues.apache.org/jira/browse/DERBY-3309 > Project: Derby > Issue Type: Sub-task > Components: JDBC, Network Client >Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Trivial > Fix For: 10.2.2.1, 10.3.2.2, 10.4.0.0 > > Attachments: derby-3309-1a-unused_imports.diff, > derby-3309-2a-remove_unused_constructor.diff > > > A few minor cleanups: > 1) Remove unused constructor > 2) Remove unused imports > 3) Various documentation/formatting fixes > Other minor fixes will be done if required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3302: -- Priority: Critical (was: Major) I agree. Raising the priority to 'Critical' since the bug makes it impossible to access the database. > NullPointerException during recovery of database with territory-based > collation > --- > > Key: DERBY-3302 > URL: https://issues.apache.org/jira/browse/DERBY-3302 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: npe.sql > > > When logical undo is performed on a database with territory-based collation, > you may get a NullPointerException in SQLChar.getCollationKey() because > SQLChar.getLocaleFinder() returns null. > This bug was reported on derby-user: > http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557635#action_12557635 ] Thomas Vatter commented on DERBY-3302: -- This bug occured during the last week estimatedly every 32 hours, so I would ask for giving it a higher priority, as critical or blocker. tom_ > NullPointerException during recovery of database with territory-based > collation > --- > > Key: DERBY-3302 > URL: https://issues.apache.org/jira/browse/DERBY-3302 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Mamta A. Satoor > Attachments: npe.sql > > > When logical undo is performed on a database with territory-based collation, > you may get a NullPointerException in SQLChar.getCollationKey() because > SQLChar.getLocaleFinder() returns null. > This bug was reported on derby-user: > http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3310: -- Derby Info: [Regression] Marking this as a regression since it worked fine in rev 540921, and possibly later. > ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions > -- > > Key: DERBY-3310 > URL: https://issues.apache.org/jira/browse/DERBY-3310 > Project: Derby > Issue Type: Bug > Components: SQL >Reporter: Dyre Tjeldvoll >Priority: Minor > Attachments: cast-repro.sql > > > The following code > CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); > -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) > INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 > FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; > gives > ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class > org.apache.derby.iapi.types.SQLInteger) expected to be the same as > col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): > org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3309) Minor cleanups in ClientPooledConnection40 and ClientPooledConnection
[ https://issues.apache.org/jira/browse/DERBY-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3309: --- Attachment: derby-3309-1a-unused_imports.diff 'derby-3309-1a-unused_imports.diff' removes unused imports from ClientPooledConnection40. Committed to trunk with revision 610404. Merged to 10.3 with revision 610766. Merged to 10.2 with revision 610767. > Minor cleanups in ClientPooledConnection40 and ClientPooledConnection > - > > Key: DERBY-3309 > URL: https://issues.apache.org/jira/browse/DERBY-3309 > Project: Derby > Issue Type: Sub-task > Components: JDBC, Network Client >Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Trivial > Fix For: 10.2.2.1, 10.3.2.2, 10.4.0.0 > > Attachments: derby-3309-1a-unused_imports.diff > > > A few minor cleanups: > 1) Remove unused constructor > 2) Remove unused imports > 3) Various documentation/formatting fixes > Other minor fixes will be done if required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3297) Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions.
[ https://issues.apache.org/jira/browse/DERBY-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557590#action_12557590 ] Thomas Nielsen commented on DERBY-3297: --- Let me add a short description of the changes as well M src/ref/refderby.ditamap <-- toc.html Adds the additional functions to the list of built-in function, in alphabetically correct position. A src/ref/rreffunccosh.dita A src/ref/rreffunctanh.dita A src/ref/rreffuncsinh.dita A src/ref/rreffunccot.dita A src/ref/rreffuncrand.dita A src/ref/rreffuncrandom.dita A src/ref/rreffuncsign.dita New files describing the functions COSH, TANH, SINH, COT, RAND, RANDOM and SIGN. Based on the existing topic for SIN, but changed according to StrictMath. RAND and RANDOM was made separate topics in the TOC, but RAND xrefs RANDOM. > Document SIGN, SQRT, RAND, RANDOM, COSH, COT, SINH and TANH functions. > -- > > Key: DERBY-3297 > URL: https://issues.apache.org/jira/browse/DERBY-3297 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Daniel John Debrunner >Assignee: Thomas Nielsen >Priority: Minor > Attachments: d3297-doc-1.diff, d3297-doc-1.stat, rreffunccosh.html, > rreffunccot.html, rreffuncrand.html, rreffuncrandom.html, rreffuncsign.html, > rreffuncsinh.html, rreffunctanh.html, toc.html > > > These functions were added by DERBY-1808 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2733) ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1.
[ https://issues.apache.org/jira/browse/DERBY-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557587#action_12557587 ] John H. Embretsen commented on DERBY-2733: -- Thank you for doing this Myrna, it is a great improvement! The code change works fine with my Java ME VM (phoneME Advanced). I will comment on the doc changes below, but first I'd like to present my view of how this should ideally work: - I think it would be easier to use IJ with a datasource (and to document it) if IJ tries to connect automatically to a database ONLY IF ij.dataSource.databaseName is set. It makes no sense doing it otherwise. - If ij.dataSource.databaseName is set, and IJ successfully connects to the database automatically on startup, this should be indicated to the user, e.g. "Connected to database [databaseName]". Given the current implementation, I have the following comments regarding the doc changes: First, I think it would be useful to explicitly say that ij will try to connect to your database automatically when you specify ij.dataSource. E.g. "When you set the ij.dataSource property ij will automatically try to connect to a database. To establish a connection to a specific database using ij.dataSource, set the ij.dataSource.databaseName property. If you do not set this property, ij will start with an error..." It's awkward, but I think it is needed given the current implementation. Second, I think the sentence "If you do not specify ij.dataSource.databaseName, you can still connect to a database after the error indicating that no database was found, but you should not specify the protocol, just the databasename, in the connect statement." is a bit long and complex (I almost lose my breath reading it). Besides, I think "just the databasename" may be misleading (because you may include connection attributes as well), and that we should say "connect command" instead of "connect statement" (because that is how it is described in the Tools guide). I suggest the following: "If you do not specify ij.dataSource.databaseName and get an error indicating that no database was found, you can still connect to a database manually by using ij's connect command. You should not specify the protocol (for example jdbc:derby:) in the connect command when using ij.dataSource." Actually, I think Example 2 as it is in the current doc trunk is useful to show this "feature", but it should include the error message: java -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource org.apache.derby.tools.ij ERROR XJ004: Database '' not found. ij version 10.4 ij> connect 'smalldb;create=true'; ij> The doc page should include a reference to the documentation for the connect command. Finally, the documentation for the connect command ( http://db.apache.org/derby/docs/dev/tools/rtoolsijcomref22318.html ) says: "Connects to the database indicated by the ConnectionURLString. Specifically, takes the value of the string database connection URL and issues a java.sql.DriverManager.getConnection request to set the current connection to that database connection URL." which is incorrect if you specify ij.dataSource (and do not include the protocol in the URL - sigh...). Something like this is more correct, I guess: "Connects to the database indicated by the ConnectionURLString. Specifically, ij takes the value of the string (the database connection URL) and issues a getConnection request using java.sql.DriverManager or a javax.sql.DataSource implementation (see the ij.dataSource property) to set the current connection to that database connection URL." (If the connect command docs should be handled in a separate Jira, feel free to create one, or let me know so I can do it myself). > ij rolls through NullPointerException (NPE) with J2ME/JSR169/WEME 6.1. > -- > > Key: DERBY-2733 > URL: https://issues.apache.org/jira/browse/DERBY-2733 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4 > Environment: windows xp; j9 -jcl:foun11 -version: > java version "J2ME Foundation Specification v1.1" > IBM J9 2.3 Windows XP x86-32 (JIT enabled) > J9VM - 20061023_08962_lHdSMR > JIT - 20060629_1804ifx1_r8 > GC - 200609_15 > JCL - 20061020_1321,foun11 > Licensed Materials - Property of IBM > J9 - VM for the Java(TM) platform, Version 2.3 > (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved > Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86) > JIT - 20060629_1804ifx1_r8 >Reporter: Myrna van Lunteren >Assignee: Myrna van Lunteren > Attachments: DERBY-2733-doc.diff, DERBY-2733-src.diff, > DERBY-2733.diff2, DERBY-2733_3.diff, DERBY-2733_doc_3.diff, > DERBY-2733_doc_4.diff,
[jira] Commented: (DERBY-3312) Local Network Server Performance
[ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557583#action_12557583 ] Øystein Grøvlen commented on DERBY-3312: Are you saying that retrieving records over the network is faster than local retrieval? Or just that the slow-down with the new version is larger for local retrieval than for remote retrieval? If the former, it sounds like running the clients and the server on the same computer makes the system CPU-bound. That is, that either clients or server or both use more CPU with 10.3. I would very much like to be able to reproduce your problems. If possible, it would be nice if you could post the DDL for the table and some information about size distribution for the Blobs involved. (If I understand you correctly there is max. 500 rows in the table.) Also of interest is what the clients do (JDBC code)? Is it just a sequence of getXXX calls for selected columns of the table? > Local Network Server Performance > > > Key: DERBY-3312 > URL: https://issues.apache.org/jira/browse/DERBY-3312 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 > Environment: Intel x86 based server SuSE Linux Enterprise Server 10 > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Derby 10.3.2.1 >Reporter: Timothy Graf > > We have a Java based XML-RPC client/server product that incorporates an > embedded Derby database and network server. Our client uses the derby JDBC > ndriver and network client to connect to the Derby Network Server. > We recently moved from Cloudscape, which I believe used the 10.1.3.1 Derby > code, because of other issues which seem to be resolved by moving to the > latest Derby release. We have a very simple database with a simple table. > This table does include BLOBs, however its size has not been an issue and we > limit our records to 500. > Since moving to the latest release of Derby, version 10.3.2.1, we noticed > that our clients running on the same machine as our server take much longer > to retrieve a list of records from the database. Our clients running on a > remote machine do not seem to have any performance issues when retrieving the > same list of records. > We start our Network Server in Java through the API so I don't think the > Security Manager is the issue. I read that performance could be affected by > the Security Manager, but according to the Derby documentation, > "The Network Server will not attempt to install a security manager if you > start the server from your application using the programmatic API ..." > I tried going back several releases of Derby and the performance issue seems > to go away when I run with version 10.1.3.1 of Derby. However we see the > same issue that we saw with Cloudscape in that we can not turn off connection > logging. We also had stability problems with the Network Server with > Cloudscape. > We would really prefer to use the latest Derby release however the > performance issues are a sever limitation. I thought that maybe this was a > simple Network Server configuration issue however after researching this > issue I have not found anything from a configuration standpoint that may help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Possible NPE code bug in DRDAConnThread.writeSQLCINRD - any ideas??
Daniel John Debrunner <[EMAIL PROTECTED]> writes: > In DRDAConnThread.writeSQLCINRD() at line 4129 we have: > > ResultSet rs = null; > > ... > > if (!stmt.needsToSendParamData)<<< line 4129 >rs = stmt.getResultSet(); > > > then later at line 4137 we access rs regardless of its setting: > >ResultSetMetaData rsmeta = rs.getMetaData(); > > this will lead to an NPE if stmt.needsToSendParamData was true. > > Any ideas on what is going on here? Should the test of > needsToSendParamData be removed? I think the test is there to ensure that we don't send the result set until all out parameters (for callable statements) have been sent. The only place writeSQLCINRD() is called, stmt.finishParams() is called first, so needsToSendParamData is always false when writeSQLCINRD() is called. Since the intention seems to be that !needsToSendParamData is a precondition for writeSQLCINRD(), I think it would be fine to replace the test with an assert. -- Knut Anders
