Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
I am not sure where the following information is contained, but somehow
the log statement text trace in a network server connection use to
associate a session id with a connection. So derby.log statments
would be tagged with this info. This is what I always used
to understand the path of a connection within the log (often people will
use thread id which can work, but does not work if connection pooling
is involved). This did not provide any sort of unique id for a given
network server, though I don't know if that is necessary.
Maybe someone knows if this info is available to the EmbedConnection
class, maybe from the context manager?
David Van Couvering wrote:
Hi, Kathey. Currently the connection classes don't appear to have a
unique identifier that could be made available in toString(). Do I take
it you would like me to find an approach that generates one?
I noticed Derby has a UUID service (very nice!). Is it OK if I use that
here to generate a UUID for the connection? If I don't hear otherwise,
I'll assume this approach is OK, e.g.
public class EmbedConnection
{
private UUID UUIDValue;
private String UUIDString;
public EmbedConnection()
{
UUIDFactory uuidFactory = Monitor.getMonitor().getUUIDFactory();
UUIDValue = uuidFactory.createUUID();
UUIDString = this.getClass().getName() + : + UUIDValue.toString();
...
}
public String toString()
{
UUIDString;
}
}
=
The connection classes I found are as follows. Please let me know if I
missed any. An indented class implies it extends the unindented class
above it.
EMBEDDED (org.apache.derby.engine.*)
BrokeredConnection (implements java.sql.Connection)
BrokeredConnection30
EmbedConnection (implements java.sql.Connection)
EmbedConnection30
EmbedPooledConnection (implements java.sql.PooledConnection)
EmbedXAConnection
CLIENT (org.apache.derby.client.*_
Connection (abstract class, implements java.sql.Connection))
NetConnection
NetXAConnection
ClientXAConnection (implements java.sql.XAConnection)
ClientPooledConnection (implements java.sql.PooledConnection)
LogicalConnection (implements java.sql.Connection)
On the client side, I first need to understand: is derbyclient.jar
supposed to be standalone (meaning it can't depend upon things in
derby.jar like the Monitor and the UUID class). If so, I suppose I
could cut/paste the BasicUUID class into the client packages for use on
the client side (shiver). Alternately we could have a derbyutils.jar
that is shared between client and server (Big Change, not sure if I want
to take that on). Advice here would be most appreciated.
Thanks,
David
Kathey Marsden (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
Kathey Marsden updated DERBY-243:
-
Summary: connection toString should uniquely identify the
connection (was: connection toString doesn't give enough information)
Description: The toString() on the Derby connection doesn't print
unique information.
for example System.out.println(conn) prints:
EmbedConnection in the case of derby embedded
It would be great if the toString() method for connections could be
used to differentiate one connection from another.
was:
The toString() on the Derby connection doesn't print unique information.
for example System.out.println(conn) prints:
EmbedConnection in the case of derby embedded
I am not sure if XA Connections and Pooled Connections have the same
issue. I didn't immediately see an override of the toString() method
in BrokeredConnection.java like there is for EmbedConnection
connection toString should uniquely identify the connection
---
Key: DERBY-243
URL: http://issues.apache.org/jira/browse/DERBY-243
Project: Derby
Type: Improvement
Components: JDBC
Reporter: Kathey Marsden
Assignee: David Van Couvering
Priority: Trivial
Fix For: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0
The toString() on the Derby connection doesn't print unique information.
for example System.out.println(conn) prints:
EmbedConnection in the case of derby embedded
It would be great if the toString() method for connections could be
used to differentiate one connection from another.
[PATCH] Derby 218 - Add relaxed durability option
A little background: Sometime earlier on the list, Dan posted a fix to make derby go faster with relaxed durability with some flags. The post is at http://article.gmane.org/gmane.comp.apache.db.derby.user/681/match=relaxed+durability This mode is very useful for unit testing or at development time when recoverability is not required. Basically in this mode, syncs are disabled for logs, data writes at checkpoint, page allocation when file is grown; - what this means is that data is not flushed all the way to the disk and in most cases i/o cost is not involved. Note, code already exists in Derby to do this. So for Derby 218, This patch addresses the following requirements: 1) Have a single property to enable this relaxed durability mode, so it is easy for users to enable it. 2) Print message to derby.log that this mode is enabled 3) A way to report boot errors that may be because of this option being enabled. What this maps to is - have a marker to recognize that database was booted in this mode, and then on subsequent boot; if errors happen during recovery - report a message that it could have happened because of this mode being set. Changes are not much. svn stat M java\engine\org\apache\derby\impl\store\raw\log\LogToFile.java M java\engine\org\apache\derby\impl\store\raw\data\BaseDataFileFactory.java M java\engine\org\apache\derby\impl\store\raw\data\RAFContainer.java M java\engine\org\apache\derby\iapi\reference\MessageId.java M java\engine\org\apache\derby\iapi\reference\Property.java M java\engine\org\apache\derby\loc\messages_en.properties A java\testing\org\apache\derbyTesting\functionTests\tests\store\TestNoSyncMode.java M java\testing\org\apache\derbyTesting\functionTests\tests\store\copyfiles.ant A java\testing\org\apache\derbyTesting\functionTests\tests\store\TestNoSyncMode_derby.properties A java\testing\org\apache\derbyTesting\functionTests\master\TestNoSyncMode.out M java\testing\org\apache\derbyTesting\functionTests\suites\storemats.runall Since this is a longish email , for those who may not read the rest of it, here are the testing results Testing results: - I ran derbyall with 1.4.2 jvm and all tests passed. - I ran the storeall suite separately both with setting the derby.system.testMode property to true and without it. with this property set, the storeall suite ran about 2 times as fast. --- Below I explain how the patch addresses the above requirements and try to provide details on how I went about making those changes 0) Note 1) A single property has been added to enable this relaxed durability option. The property name is derby.system.testMode and takes in value true or false. By default it is false. It can be set as a command line option to the JVM when starting the application or within the application or in the derby.properites file. Property is loaded at boot time, so for it to have an effect you need to enable it at boot time. More comments added in code itself. see variable TESTMODE_NO_SYNC = derby.system.testMode; in Property.java. (In this patch, I have used 'no_sync' as suffix in variable names because I think with respect to store - that is what this mode is all about - disabling syncs for the cases already mentioned earlier in this mail) I chose the property name derby.system.testMode for this - represents a higher concept as to when one would use relaxed durability (no sync) option. - mostly it should be enabled only when data is not important and ideally maybe for testing and development purposes, - also with the hope that the word 'testMode' would prompt users to look this property up before using it in a production like environment where it may not necessarily be appropriate. Code changes for this: - Added this new property derby.system.testMode in java\engine\org\apache\derby\iapi\reference\Property.java - Removed the following properties from Property.java as they are no longer required. derby.storage.dataNotSyncedAtCheckPoint=true( I'll refer to this as DNSAC in notes below) derby.storage.dataNotSyncedAtAllocation=true ( I'll refer to this as DNSAA in notes below) derby.storage.logNotSynced=true(I'll refer to this as LNS in notes below) - Previously code existed for enabling the DNSAC, DNSAA and LNS options conditional on Performance.MEASURE So how it works is , the 2 variables in BaseDataFileFactory.java are used to control if syncs happen or not for data pages at allocation and at checkpoint. dataNotSyncedAtAllocation dataNotSyncedAtCheckpoint And in java/engine/org/apache/derby/impl/store/raw/log/LogToFile, the logNotSynced variable is used to control if syncs happen for the logs are not. These variables are enabled (set to true) if Performance.MEASURE is set to true, and if the DNSAC, and DSNAA propertie are enabled. So all that is required now is -
[PATCH] fix for DERBY-235 ( unable to create a database using a different storage factory than the one provided by default with the engine)
Problem was service name on database creation was getting just set to
the canonical name of the database directory
without subsub protocol name added in the beginning. Whereas rest of the
system seems to expect that the
subsub protocol name also is part of the service name. For example
if csf is subprotocol name ,
service name should be csf:C:\suresht\databases\wombat1 not just
C:\suresht\databases\wombat1.
Attached diff fixes the problem by prefixing the subsub protocol name
to the canonical name, to generate
the service name in the case of create also.
This was not an issue with default directory subsub protocol because
the system consistently generates
the service name as just the canonical name of the service root.
Another doubt I had while fixing this issue why we generate the service
name after creating the service root,
my guess is because of the following comment in the java docs for
java.io.File.getCanonicalPath() method:
Every pathname that denotes an existing file or directory has a unique
canonical form. Every pathname that
denotes a nonexistent file or directory also has a unique canonical
form. The canonical form of the pathname of a
nonexistent file or directory may be different from the canonical form
of the same pathname after the file or
directory is created. Similarly, the canonical form of the pathname of
an existing file or directory may be different from the
canonical form of the same pathname after the file or directory is deleted.
Tests: Ran derbyall ; all tests passed.
Thanks
-suresh
Index:
java/engine/org/apache/derby/impl/services/monitor/PersistentServiceImpl.java
===
---
java/engine/org/apache/derby/impl/services/monitor/PersistentServiceImpl.java
(revision 165030)
+++
java/engine/org/apache/derby/impl/services/monitor/PersistentServiceImpl.java
(working copy)
@@ -629,7 +629,15 @@
Throwable t = null;
try
{
-return (String) AccessController.doPrivileged(
+ String protocolLeadIn = ;
+ //prepend the subsub protocol name to the storage
factoty canonical
+ //name to form the service name except in case of the
the
+ //default subsubprototcol(PersistentService.DIRECTORY)
+
+ if (!(getType().equals( PersistentService.DIRECTORY)))
+ protocolLeadIn = getType() + :;
+
+return protocolLeadIn + (String) AccessController.doPrivileged(
new PrivilegedExceptionAction()
{
public Object run()
Re: assigning a jira
I have added 'lancea' to derby-developer list. Also added Shreyas. You should be able to assign and close bugs now. Satheesh Lance J. Andersen wrote: thanks, i just sent him an email. Regards lance Andrew McIntyre wrote: On Apr 29, 2005, at 11:44 AM, Lance J. Andersen wrote: Perhaps it is me, but I swear i used to be able to assign myself a jira. Now i cannot find a way to do this. Any special access needed? To assign issues to yourself, you do need to be added as a developer to a specific project, and I don't currently see you in the list of Derby developers. Satheesh has admin rights to Jira I believe, so send him your Jira userid and he should be able to add you to the project. andrew
[jira] Assigned: (DERBY-237) Boot errors from store must not lose error messages/stack traces in between.
[ http://issues.apache.org/jira/browse/DERBY-237?page=all ] Sunitha Kambhampati reassigned DERBY-237: - Assign To: Sunitha Kambhampati Boot errors from store must not lose error messages/stack traces in between. Key: DERBY-237 URL: http://issues.apache.org/jira/browse/DERBY-237 Project: Derby Type: Bug Components: Store Versions: 10.1.0.0 Environment: all Reporter: Sunitha Kambhampati Assignee: Sunitha Kambhampati Boot errors from store do not show the entire stack traces of the nested exceptions We need to print the entire stack trace without losing exceptions in between. This will save time to debug errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: assigning a jira
Satheesh Bandaram wrote: I have added 'lancea' to derby-developer list. Also added Shreyas. You should be able to assign and close bugs now. For future reference there is a good writeup on Jira Derby at http://incubator.apache.org/derby/DerbyBugGuidelines.html and (linked from the page above) http://incubator.apache.org/derby/binaries/FilingDerbyIssuesInJira.doc It includes the information on how to get access to be able to assign, close bugs etc. Dan.
[jira] Assigned: (DERBY-247) Network Server demo program should support Derby network client driver
[ http://issues.apache.org/jira/browse/DERBY-247?page=all ] Lance Andersen reassigned DERBY-247: Assign To: Lance Andersen Network Server demo program should support Derby network client driver -- Key: DERBY-247 URL: http://issues.apache.org/jira/browse/DERBY-247 Project: Derby Type: Improvement Components: Demos/Scripts Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Assignee: Lance Andersen Priority: Minor Currently, the Network Server demo programs require the IBM Universal JDBC Driver (JCC) for client functionality. The demo should be enhanced to also support using the Derby client driver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Lock-free and wait-free concurrency
I was looking to see if ++ was atomic (as I suspected it's not) and I found this very interesting article from the Blue Guys about java.util.concurrent.atomic in JDK 1.5. I am not an expert in locking, but this looked very interesting. Has anybody looked at this? Could Derby take advantage of this? http://www-106.ibm.com/developerworks/java/library/j-jtp11234/ David
Assigned bugs in Jira
Lance J. Andersen wrote: I can take this if no one else wants it. Mamta Satoor wrote: I think this is a very easy bug to fix. So, if someone is looking for an opportunity to start with a simple bug, this will be a good one. Key: DERBY-242 Assigned to: Satheesh Bandaram Just as a point of order, hopefully a Jira bug being assigned to someone means that they are actively working on it. So before trying to fix a bug it's worth checking to see if it is assigned. If you are interested in working on a bug that is assigned then you can of course offer to help out or even take over the bug completely. Dan.
Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Hm, well, I don't know this code very well, but as far as I can tell,
the EmbedConnection has an associated EmbedConnectionContext which it
creates when constructed, but this context has no unique identifier, nor
does its superclass all the way up the context stack.
I did notice that when a client connects to the network server, there is
code that creates a connection number by incrementing a variable in
DB2jServerImpl (it's disconcerting that it's not synchronized), and that
this number is passed to the Session object, and that Session appears to
use this when outputting traces (but I was a bit lost by then).
But this is not the same as what Kathey is looking for. Perhaps it
could be found by EmbedConnection (I actually hope not, as that would
indicate circular dependencies), but even so it would only be available
for EmbedConnections that were created to service a session from a
remote client.
Is there a preference to have the unique id to be in the
ConnectionContext rather than in the Connection? I don't fully
understand the roles and responsibilities of Context vs. the object it
contextizes :) so I'd appreciate the guidance. My intuition says
simplicity dictates it goes in the Connection, but let me know if I'm
wrong...
I will note that in general the approach for generating unique ids
appears to be incrementing variables rather than using UUID. In my
searches for the mysterious session id, I saw two instances of this
GenericLanguageConnectionFactory.getNextLCCInstanceNumber()
and
DB2jServerImpl.getNewConnNum()
this latter one is called whenever a new client thread is created, I am
pretty sure this is Mike's session id.
So, I am leaning towards the increment approach for generating a new
connection id rather than using UUID, especially since it will work in
the client code as well.
Thanks,
David
Mike Matrigali wrote:
I am not sure where the following information is contained, but somehow
the log statement text trace in a network server connection use to
associate a session id with a connection. So derby.log statments
would be tagged with this info. This is what I always used
to understand the path of a connection within the log (often people will
use thread id which can work, but does not work if connection pooling
is involved). This did not provide any sort of unique id for a given
network server, though I don't know if that is necessary.
Maybe someone knows if this info is available to the EmbedConnection
class, maybe from the context manager?
David Van Couvering wrote:
Hi, Kathey. Currently the connection classes don't appear to have a
unique identifier that could be made available in toString(). Do I
take it you would like me to find an approach that generates one?
I noticed Derby has a UUID service (very nice!). Is it OK if I use
that here to generate a UUID for the connection? If I don't hear
otherwise, I'll assume this approach is OK, e.g.
public class EmbedConnection
{
private UUID UUIDValue;
private String UUIDString;
public EmbedConnection()
{
UUIDFactory uuidFactory = Monitor.getMonitor().getUUIDFactory();
UUIDValue = uuidFactory.createUUID();
UUIDString = this.getClass().getName() + : + UUIDValue.toString();
...
}
public String toString()
{
UUIDString;
}
}
=
The connection classes I found are as follows. Please let me know if
I missed any. An indented class implies it extends the unindented
class above it.
EMBEDDED (org.apache.derby.engine.*)
BrokeredConnection (implements java.sql.Connection)
BrokeredConnection30
EmbedConnection (implements java.sql.Connection)
EmbedConnection30
EmbedPooledConnection (implements java.sql.PooledConnection)
EmbedXAConnection
CLIENT (org.apache.derby.client.*_
Connection (abstract class, implements java.sql.Connection))
NetConnection
NetXAConnection
ClientXAConnection (implements java.sql.XAConnection)
ClientPooledConnection (implements java.sql.PooledConnection)
LogicalConnection (implements java.sql.Connection)
On the client side, I first need to understand: is derbyclient.jar
supposed to be standalone (meaning it can't depend upon things in
derby.jar like the Monitor and the UUID class). If so, I suppose I
could cut/paste the BasicUUID class into the client packages for use
on the client side (shiver). Alternately we could have a
derbyutils.jar that is shared between client and server (Big Change,
not sure if I want to take that on). Advice here would be most
appreciated.
Thanks,
David
Kathey Marsden (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
Kathey Marsden updated DERBY-243:
-
Summary: connection toString should uniquely identify the
connection (was: connection toString doesn't give enough information)
Description: The toString() on the Derby connection doesn't print
unique information.
for example System.out.println(conn) prints:
Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Hm, I always thought a hash-code was not unique. I got excited when you
mentioned this method, identityHashCode(), which I hadn't heard of, but
it basically delegates to Object.hashCode(), it just ensures that the
hash code returned is the base Object hash code and not one returned by
an overriding method.
The documentattion for hashCode() says
It is not required that if two objects are unequal according to the
equals(java.lang.Object) method, then calling the hashCode method on
each of the two objects must produce distinct integer results. However,
the programmer should be aware that producing distinct integer results
for unequal objects may improve the performance of hashtables.
As much as is reasonably practical, the hashCode method defined by
class Object does return distinct integers for distinct objects. (This
is typically implemented by converting the internal address of the
object into an integer, but this implementation technique is not
required by the JavaTM programming language.)
So, we can depend on it *most* of the time, but that makes me a bit
nervous...
David
Jack Klebanoff wrote:
The simplest thing would be to use the java.lang.System.identityHashCode
method on the connection object. I believe that it is unique in a 32 bit
system. In practice it will almost always be unique in a 64 bit system.
I don't think that the Monitor or UUIDFactory classes are available in
the client.They are part of the Derby server.
Jack Klebanoff
||David Van Couvering wrote:
One thought I had about the UUID approach, after proposing it, is that
if you're trying to correlate connections and trace messages and you
have these huge long UUID strings, it can be a bit challenging.
If it were a simple static long that starts at 1 and increments each
time a new connection instance is created (yes, the increment would
have to be synchronized), then it would be much more readable. This
would also be more portable to the client code, and we wouldn't have
to cut/paste the UUID class to the client packages...
Any thoughts?
Thanks,
David
David Van Couvering wrote:
Hi, Kathey. Currently the connection classes don't appear to have a
unique identifier that could be made available in toString(). Do I
take it you would like me to find an approach that generates one?
I noticed Derby has a UUID service (very nice!). Is it OK if I use
that here to generate a UUID for the connection? If I don't hear
otherwise, I'll assume this approach is OK, e.g.
public class EmbedConnection
{
private UUID UUIDValue;
private String UUIDString;
public EmbedConnection()
{
UUIDFactory uuidFactory = Monitor.getMonitor().getUUIDFactory();
UUIDValue = uuidFactory.createUUID();
UUIDString = this.getClass().getName() + : + UUIDValue.toString();
...
}
public String toString()
{
UUIDString;
}
}
=
The connection classes I found are as follows. Please let me know if
I missed any. An indented class implies it extends the unindented
class above it.
EMBEDDED (org.apache.derby.engine.*)
BrokeredConnection (implements java.sql.Connection)
BrokeredConnection30
EmbedConnection (implements java.sql.Connection)
EmbedConnection30
EmbedPooledConnection (implements java.sql.PooledConnection)
EmbedXAConnection
CLIENT (org.apache.derby.client.*_
Connection (abstract class, implements java.sql.Connection))
NetConnection
NetXAConnection
ClientXAConnection (implements java.sql.XAConnection)
ClientPooledConnection (implements java.sql.PooledConnection)
LogicalConnection (implements java.sql.Connection)
On the client side, I first need to understand: is derbyclient.jar
supposed to be standalone (meaning it can't depend upon things in
derby.jar like the Monitor and the UUID class). If so, I suppose I
could cut/paste the BasicUUID class into the client packages for use
on the client side (shiver). Alternately we could have a
derbyutils.jar that is shared between client and server (Big Change,
not sure if I want to take that on). Advice here would be most
appreciated.
Thanks,
David
Kathey Marsden (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
Kathey Marsden updated DERBY-243:
-
Summary: connection toString should uniquely identify the
connection (was: connection toString doesn't give enough information)
Description: The toString() on the Derby connection doesn't
print unique information.
for example System.out.println(conn) prints:
EmbedConnection in the case of derby embedded
It would be great if the toString() method for connections could be
used to differentiate one connection from another.
was:
The toString() on the Derby connection doesn't print unique
information.
for example System.out.println(conn) prints:
EmbedConnection in the case of derby embedded
I am not sure if XA Connections and Pooled Connections have the same
issue. I didn't immediately see
[jira] Commented: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
[
http://issues.apache.org/jira/browse/DERBY-214?page=comments#action_64106 ]
Craig Russell commented on DERBY-214:
-
Hi,
I agree that main() should only be used from the command line, and is the only
place in the code where System.exit() should be called. The main() method could
simply delegate to another method that takes the String args[] parameter. For
the purposes of this message, I'll just call it execute.
All of the utility programs should use the same method name for the execute
method so it's easy to remember how to invoke it. The execute then does the
parsing of the args. There are lots of Apache commons arg parsers that could be
used in the execute, but that's just a bit off topic.
Execute should throw exceptions, not ever call System.exit. Since the execute
method has the same parameters as main, it's easy to remember how to invoke it.
The second issue is whether the execute method should be static or not. For
consistency, I think that non-static would be the way to go. If we offer
different methods of executing, then it would be nice to have all of them
behave the same in terms of static vs. non-static.
The third issue is where the processing of environment variables should be
done. It might be best if the constructor of an instance of the utility class
processed the environment variables. That way, regardless of whether main() or
a program called the constructor the behavior would be the same.
The fourth issue is whether for ease of use, aother convenience methods could
be used. One that takes a single String is desirable. This method, also called
execute, could simply parse the input String into a String[] and call the other
execute method. An alternative method would take a Map of parameter names and
values with the obvious semantics.
I see a few alternatives
1. ij.execute(new String[] {{-p, 1567, -h, localhost });
2. ij.setPort(1567); ij.setHost(localhost);ij.execute();
3. ij.execute(-p 1567 -h localhost);
4. Map map = new HashMap(); map.put(-p, 1567); map.put(-h, localhost);
ij.execute(Map map);
I can see value in all of these techniques depending on what you have on the
caller side of the interface.
Regards,
Craig
Remove System.exit() calls from the DB2jServerImpl.java
---
Key: DERBY-214
URL: http://issues.apache.org/jira/browse/DERBY-214
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.1.0.0
Reporter: Kathey Marsden
Assignee: David Van Couvering
The System.exit() calls needs to be removed from the
DB2jServerImpl.java as this results in the entire application
(example - Eclipse which is running the Network Server inside
it) getting shut down.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Assigned bugs in Jira
No problem.. You can keep it. :-) I suspect Dan was making a general statement since we have seen more active developers on the list recently. One should always assign a defect they are actively working on, unassigns if they have stopped working on it for any reason. Go Derby! Satheesh Lance J. Andersen wrote: Sorry, I assumed when Mamta sent the email that it was the intent for someone to take this over. I can reassign this back to Satheesh if you like. I just assumed it was unassigned given the email was sent out. I did noticce when I assigned it that it showed Satheesh as the owner. Just let me know. Regards Lance Daniel John Debrunner wrote: Lance J. Andersen wrote: I can take this if no one else wants it. Mamta Satoor wrote: I think this is a very easy bug to fix. So, if someone is looking for an opportunity to start with a simple bug, this will be a good one. Key: DERBY-242 Assigned to: Satheesh Bandaram Just as a point of order, hopefully a Jira bug being assigned to someone means that they are actively working on it. So before trying to fix a bug it's worth checking to see if it is assigned. If you are interested in working on a bug that is assigned then you can of course offer to help out or even take over the bug completely. Dan.
Re: [jira] Commented: (DERBY-203) setNull(x,JDBCType.DATE) does not work when batching is turned on
Assign the bug to yourself, to indicate you are working on it. I have added you to 'derby-developer' list now. Satheesh Shreyas Kaushik wrote: I am planning to work on this may be this week, but definitely next week. I did a similar fix for Blob and Timestamp. But as a part of the patch for this I want to solve this problem not just for this specific case but for all DataTypes where this problem could occur. ~ Shreyas Shreyas Kaushik (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-203?page=comments#action_63028 ] Shreyas Kaushik commented on DERBY-203: --- I had fixed smilar problem with Blob and Timestamp. I will look into this and other types with which this problem can arise. setNull(x,JDBCType.DATE) does not work when batching is turned on - Key: DERBY-203 URL: http://issues.apache.org/jira/browse/DERBY-203 Project: Derby Type: Bug Components: JDBC Versions: 10.0.2.1 Environment: -- Java Information -- Java Version:1.4.2_07 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/j2sdk1.4.2_07/jre Java classpath: /home/oleg/prg/cs/lib/derby.jar:/home/oleg/prg/cs/lib/derbytools.jar: OS name: Linux OS architecture: i386 OS version: 2.6.8.1-24mdk Java user name: oleg Java user home: /home/oleg Java user dir: /usr/local/home/oleg/prg/cs/frameworks/embedded/bin - Derby Information [/usr/local/home/oleg/prg/cs/lib/derby.jar] 10.0.2.0 - (30301) [/usr/local/home/oleg/prg/cs/lib/derbytools.jar] 10.0.2.0 - (30301) -- - Locale Information - -- Reporter: Oleg Anastasyev Trying to execute batch on which setNull(x,DATE) was called gives the following exception: SQL Exception: An attempt was made to get a data value of type 'DATE' from a data value of type 'null'. at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java) at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java) at org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(ConnectionChild.java) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.dataTypeConversion(EmbedPreparedStatement.java) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setObject(EmbedPreparedStatement.java) at org.apache.derby.iapi.types.DataType.setInto(DataType.java) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeBatchElement(EmbedPreparedStatement.java) at org.apache.derby.impl.jdbc.EmbedStatement.executeBatch(EmbedStatement.java) at net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:54) DATE column is nullable in db schema, so it should pass there ok. I believe the problem is in org.apache.derby.iapi.types.SQLDate, which does not implement setInto method, so DataType.setInto method is executed, calling setObject(x,null). setObject thinks this is JDBC spec violation and fails on exception. Problem exists in both 10.0.2.1 and 10.0.2.0
[jira] Assigned: (DERBY-127) Aliased Columns not recognized after group by... order by combination
[ http://issues.apache.org/jira/browse/DERBY-127?page=all ] Jack Klebanoff reassigned DERBY-127: Assign To: Jack Klebanoff Aliased Columns not recognized after group by... order by combination --- Key: DERBY-127 URL: http://issues.apache.org/jira/browse/DERBY-127 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.1 Environment: Windows XP Professional JDK 1.4 (first found in relation to Mondrian 1.0.1) Reporter: Thomas Browne Assignee: Jack Klebanoff I've been doing work to try and integrate Derby with the Mondrian ROLAP engine, which has uncovered a bug in Derby when a query involves column aliasing, a group by clause, and an order by clause. For example: Mondrian will generate the following query: select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME which should be valid SQL. I have tested this query outside of the Mondrian environment and still receive the same error which is: Column 'STORE.STORE_COUNTRY' is not in any table in the FROM list or it appears within a join specification and is outside the scope of the join specification or it appears in a HAVING clause and is not in the GROUP BY list. SQL State: 42x04 Error Code: 3 However, if I remove any one of the three elements (aliasing, group by, order by) or if the order by uses the aliased names, the query works. It is only the combination of all 3 elements that is causing a problem. [ie. all of the following queries work correctly] select STORE.STORE_COUNTRY , STORE.STORE_STATE , STORE.STORE_CITY , STORE.STORE_NAME , STORE.STORE_TYPE , STORE.STORE_MANAGER , STORE.STORE_SQFT , STORE.GROCERY_SQFT , STORE.FROZEN_SQFT , STORE.MEAT_SQFT , STORE.COFFEE_BAR , STORE.STORE_STREET_ADDRESS from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS order by c0,c1,c2,c3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lock-free and wait-free concurrency
David Van Couvering wrote: I was looking to see if ++ was atomic (as I suspected it's not) and I found this very interesting article from the Blue Guys about java.util.concurrent.atomic in JDK 1.5. I am not an expert in locking, but this looked very interesting. Has anybody looked at this? Could Derby take advantage of this? http://www-106.ibm.com/developerworks/java/library/j-jtp11234/ David I think there is a lot of stuff in j.u.concurrent that Derby could use, if only we could get a 1.5 version going ;-) With the 1.1 J2ME profiles that support the 1.4 APIs now in PFD perhaps we should look at the platform roadmap going forward. Perhaps a split would be appropriate between a platform for embedded devices (based on CDC 1.1 and JSR-169) with little concurrent access and limited resources and multi-user standalone/J2EE servers (based on 1.5) optimized for high concurrent access with unconstrained resources. -- Jeremy
Re: Lock-free and wait-free concurrency
scott hutinger wrote: Jeremy Boynes wrote: David Van Couvering wrote: I was looking to see if ++ was atomic (as I suspected it's not) and I found this very interesting article from the Blue Guys about java.util.concurrent.atomic in JDK 1.5. I am not an expert in locking, but this looked very interesting. Has anybody looked at this? Could Derby take advantage of this? http://www-106.ibm.com/developerworks/java/library/j-jtp11234/ David I think there is a lot of stuff in j.u.concurrent that Derby could use, if only we could get a 1.5 version going ;-) With the 1.1 J2ME profiles that support the 1.4 APIs now in PFD perhaps we should look at the platform roadmap going forward. Perhaps a split would be appropriate between a platform for embedded devices (based on CDC 1.1 and JSR-169) with little concurrent access and limited resources and multi-user standalone/J2EE servers (based on 1.5) optimized for high concurrent access with unconstrained resources. -- Jeremy One more fluff. If your going to do any type of 'embedded' type of work with something such as derby, then you really need the jit source code, plus the rest of the code. I don't see a jit off-the-shelf giving enough information about everything needed (although I very well could be wrong, often I am). Something the size of derby needs to have a bunch of 'extra' inclusions of code for getting needed information with some possible additions. Of course, every architecture is different, but I think after getting one architecture down with some fairly good conclusions on useage, that others could follow (somewhat) closely. I think the useage differences of users also create the need of jit source. scott (just an alternative view of things (fluff)) I was just thinking about this whole thing based on the VM versions/J2ME etc. I was a bit worried about what complexities are induced by moving forward and keeping older code from getting bit-rot etc. A big portion of this is related to architectures that are not supported in some type of easy to download VM. Currently Derby is running without problems on a Zaurus C3000 (4gig hard drive); although somewhat low on resources, I wouldn't call it starved. But, most of the embedded devices are of a processor nature that are not fully supported by some of the larger 'units' in the industry. But J2ME solves a lot of those problems. I hate to harp on the subject, but getting newer alternative processor VM's up and running are person resource dependent with the newer vm's past 1.3. Now, what are the differences between J2ME and a non-hotspot/jit VM of 1.3.x? I say anything that has a jit or hotspot starts to take over anything else. Although if one is resource lean, then what are the trade-offs for the jit? Smart jit, major jit, jit hotspots, jit what? (J2ME looks like it has some nice controls on fine tuning this). The line here is getting to the point of what can people currently get for a VM on a strange processor that people can really use now. I diverge (normal). The point of all this is I don't have a clue about the architecture of Derby. It needs to move forward without too many constraints on backward compatibility. But from the other point of view, it's nice to have a code base still intact that older VM's can use. BTW, the article is nice; but I thought atomic was all that existed in the world :-) I haven't followed the complete thought processes of how older VM's are going to reach EOL (end of life cycle). Perhaps the xbox will create some handhelds that are ppc related... It would be nice to have a bit more facts on J2ME/derby/jitted methods/ and resource needs etc. But that would be a future project. scott
Re: [PATCH] Derby-250 With client setObject( parameterIndex, x, java.sql.DOUBLE) throws conversion exception if the object passed is a BigDecimal with more than 31 digits
Daniel John Debrunner wrote: So what happens if the value passed has more than 31 digits? Does the placement of the decimal point affect the behaviour? E.g. what's the outcome for these values? 12345678901234567890123456789012 1.2345678901234567890123456789012 I have a feeling I might not quite be getting your question but will take a stab at it. They get converted on the client and will insert into the double column but lose precision as they do with embedded.. For these inserted values: new BigDecimal(12345678901234567890123456789012) -- 1.2345678901234567E31 new BigDecimal(1.2345678901234567890123456789012) --1.2345678901234567 There is still an issue with setBigDecimal which will still throw an exception with these values with the client. A solution to that one is not as clear to me, but I will file a bug for it. Thanks Kathey
Re: Updated snapshot jars
Andrew: Gave 10.1 alpha it a quick shot in Network Server mode on Windows today. One quick observation: setNetworkServerCP.bat sets the CLASSPATH to point to the derby.jar, etc. files in DERBY_INSTALL/lib/ -- however, in the ZIP file the jar files are in the root directory. I had to modify setNetworkSetCP.bat accordingly to get the CLASSPATH set up correctly. At a minimum, either the batch file should be updated, or the zip file should be placed entirely within a /lib/ directory (which is kind of a generic name.) Ideally, all of the files should be contained in a descriptively named directory (derby, perhaps), and the batch file should be updated to match. Dan On 4/29/05, Andrew McIntyre [EMAIL PROTECTED] wrote: Hello all, This afternoon I updated the snapshot jars posted on the downloads page. It would be great for anyone interested in the Derby network client driver which was recently added to the trunk (10.1.0.0 alpha), or any other recently added feature or bugfix in which you are interested, to test them out and report your findings. Those interested in testing Derby on their favorite platform/JVM will find the corresponding derbyTesting.jar in the snapshot file. Also, please note that the zip snapshots were generated on Windows and the tar.gz snapshots were generated on Unix, so text files in the snapshots should have the proper line endings. Here are the highlights for each new snapshot: 10.1.0.0 alpha - FOR TESTING ONLY. Please see the warning about using alpha releases on the downloads page: http://incubator.apache.org/derby/derby_downloads.html#Development+trunk - Derby network client driver added. Use the included derbyclient.jar in place of db2jcc.jar. Additional information on its use can be found in the functional specification attached to this post: http://article.gmane.org/gmane.comp.apache.db.derby.devel/2960 - DATE and TIMESTAMP functions which correctly match the documentation - First phase of online compress functionality - Derby-176: queries with extensive joins no longer cause java linkage error - Derby-186: Set currentPosition for scrollable cursors when moving past the last row - Derby-134: Improvement to allow ordering by expressions, instead of correlation names or column positions only. - Derby-96: beginning support for recovery from out-of-order log records - Derby-106: spill BackingStoreHashTables to disk to prevent out of memory errors in hash joins - DERBY-158: PRIMARY KEY does not imply NOT NULL - INTERSECT/EXCEPT support - Preliminary JSR169 support - Snapshot includes demo and scripts - Fixed Eclipse plugin version specification - Lots more that I've left out :-) 10.0.2.2 - please note that this is not an official release - LOCAL is no longer a reserved keyword - Demos and scripts included in the snapshot - Fixed Eclipse plugin version specification A full list of fixed bugs in each version can be found here: http://issues.apache.org/jira/secure/BrowseProject.jspa? id=10594subset=-1 andrew
