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: Assigned bugs in Jira
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] 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) prin
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 s
[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: Question about softupgrade mode ..
I have now added you to 'derby-developer' list, as another Derby developer. Now you should be able to assign bugs and close them once done. Thanks for getting involved with Derby and tackling important enhancements. Satheesh TomohitoNakayama wrote: > > By the way, how can I assign myself to task? > I saw next url, but could not found UI to assign myself to it... > http://issues.apache.org/jira/browse/DERBY-134 > >
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: [RESULT] [VOTE] accept derby client contribution
Hi Susan, Thanks for taking this up. I am OK with your suggestion. Should it be forrest generated or posted as is? May be we could put the current version for now and then modify it later? ;-) Satheesh Susan Cline wrote: Hi Satheesh, I can get this ready for Jean to commit. I was thinking it could go under the 'Papers' tab, http://incubator.apache.org/derby/papers/index.html, and we could create a new category called 'Derby Network Client'. It wouldn't be appropriate under the 'Derby Engine' section. Or, we could have a new 'Functional Spec' category where any future Functional Spec for anything could go as well. Do either of those sound okay? If not, please suggest where you would like the functional spec to go. Susan Satheesh Bandaram <[EMAIL PROTECTED]> wrote: Submitted Derby client source to trunk. Post any problems you notice with Derby client. Enjoy! Please use the functional spec for usage. I will work with Jean to host it at Derby website. Satheesh
Re: Question about softupgrade mode ..
Since I merged your fix into trunk, I have marked it as FIXED and closed the bug. In the future, you would be able to assign and close bugs yourself. Satheesh TomohitoNakayama wrote: > > By the way, how can I assign myself to task? > I saw next url, but could not found UI to assign myself to it... > http://issues.apache.org/jira/browse/DERBY-134
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
[jira] Assigned: (DERBY-248) Network Server frameworks scripts should support Derby network client driver
[ http://issues.apache.org/jira/browse/DERBY-248?page=all ] Lance Andersen reassigned DERBY-248: Assign To: Lance Andersen > Network Server frameworks scripts should support Derby network client driver > > > Key: DERBY-248 > URL: http://issues.apache.org/jira/browse/DERBY-248 > Project: Derby > Type: Improvement > Components: Demos/Scripts > Versions: 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Lance Andersen > > Currently the Network Server framework scripts expect the client driver to be > the IBM Universal JDBC Driver (JCC). The Network Server framework scripts > should be enhanced to support the Derby network 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
Re: Lock-free and wait-free concurrency
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 (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: Assigned bugs in Jira
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. Nothing to do with me. :-) > 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. As Satheesh said I was just trying to cover the general case. I think a lot of us are new to open source and we do need to define some ground rules around assignment of bugs. Something like - if you are actively working on a Jira issue then assign it to yourself or ask someone on the derby-dev list to assign to you. - if you are not actively working on a Jira issue then either unassign it, or don't assign it to yourself. If you have made some progress on it, then make some comment to that effect in the Jira entry - if you want to help out on an assigned Jira issue, volunteer on the list to help out Of course anyone can work on any Jira issue that they want to, even if it is assigned to another person, but that's their choice, to possibly duplicate effort. Dan.
Re: Assigned bugs in Jira
My apologies, I didn't notice that Satheesh had already assigned it to himself. Mamta :( On 4/29/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > 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. > > Nothing to do with me. :-) > > > 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. > > As Satheesh said I was just trying to cover the general case. I think a > lot of us are new to open source and we do need to define some ground > rules around assignment of bugs. Something like > > - if you are actively working on a Jira issue then assign it to yourself > or ask someone on the derby-dev list to assign to you. > > - if you are not actively working on a Jira issue then either unassign > it, or don't assign it to yourself. If you have made some progress on > it, then make some comment to that effect in the Jira entry > > - if you want to help out on an assigned Jira issue, volunteer on the > list to help out > > Of course anyone can work on any Jira issue that they want to, even if > it is assigned to another person, but that's their choice, to possibly > duplicate effort. > > Dan. > >
Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
David Van Couvering wrote: > 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), I think perhaps the reason it is not synchronized is because there is just one ClientThread object listening on the socket, assigning connection numbers and creating connections. > 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. Sounds good to me from a usability perspective. When forced to pour over a trace I find it much easier to tell 1 from 2 than one UUID from another. Kathey
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=10594&subset=-1
>
> andrew
>
>
[jira] Assigned: (DERBY-246) XA end() fails with Connection is closed error
[ http://issues.apache.org/jira/browse/DERBY-246?page=all ]
Kathey Marsden reassigned DERBY-246:
Assign To: Kathey Marsden
> XA end() fails with Connection is closed error
> --
>
> Key: DERBY-246
> URL: http://issues.apache.org/jira/browse/DERBY-246
> Project: Derby
> Type: Bug
> Components: Network Client
> Versions: 10.1.0.0
> Environment: I am using the 10.1.0 alpha build.
> Reporter: Dibyendu Majumdar
> Assignee: Kathey Marsden
>
> I am testing ClientXADataSource.
> It fails when end() is called - here is the output fromn my test program.
> Running test org.simplejta.xatests.common.Test1
> autocommit = false
> No of rows Affected 1
> autocommit = true
> No of rows Affected 1
> org.apache.derby.client.am.XaException: XAER_RMFAIL : Connection is Closed.
> at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown
> Source)
> at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown
> Source)
> at
> org.apache.derby.client.net.NetXAResource.connectionClosedFailure(Unknown
> Source)
> at org.apache.derby.client.net.NetXAResource.end(Unknown Source)
> at org.simplejta.xatests.common.Test1.doTest(Test1.java:52)
> at org.simplejta.tests.DerbyClientTests.main(DerbyClientTests.java:66)
> Caused by: org.apache.derby.client.am.SqlException: Connection is Closed.
> ... 4 more
> Test org.simplejta.xatests.common.Test1 failed
> The test program is:
> /*
> * Test case for multiple logical connections between start() and end().
> */
> package org.simplejta.xatests.common;
> import java.sql.Connection;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.XAConnection;
> import javax.sql.XADataSource;
> import javax.transaction.xa.XAResource;
> import javax.transaction.xa.Xid;
> public class Test1 extends TestCase {
> public void doTest(XADataSource ds) throws Exception {
> // Get a XA connection to the underlying data source
> XAConnection pc1 = ds.getXAConnection();
> // Get the XA Resource
> XAResource xar1 = pc1.getXAResource();
> // Create an Xid
> Xid xid1 = Utils.createXid(1);
> // Start the XA transaction
> xar1.start(xid1, XAResource.TMNOFLAGS);
> // Get a Logical Connection
> Connection conn1 = pc1.getConnection();
> System.out.println("autocommit = " + conn1.getAutoCommit());
> // Do something with conn1
> doSomeWork1(conn1, 50);
> // Close the logical connection
> conn1.close();
> // Get another logical connection
> conn1 = pc1.getConnection();
> System.out.println("autocommit = " + conn1.getAutoCommit());
> // Do something with conn1
> doSomeWork1(conn1, 51);
> // Close the logical connection
> conn1.close();
> // END the branche
> xar1.end(xid1, XAResource.TMSUCCESS);
> // Prepare the RMs
> int prp1 = xar1.prepare(xid1);
> // Commit transaction
> xar1.commit(xid1, false);
> // Close physical connection
> pc1.close();
> }
> private void doSomeWork1(Connection conn, int deptno) throws SQLException
> {
> Statement stmt = conn.createStatement();
> int cnt = stmt
> .executeUpdate("INSERT INTO dept VALUES (" + deptno + ",
> 'BSD', 'LONDON')");
> System.out.println("No of rows Affected " + cnt);
> stmt.close();
> stmt = null;
> }
> }
> This test works fine with EmbeddedXADataSource. It also works fine with
> Oracle.
> Also, note that this error seems similar to the error I am getting with DB2
> using the DB2 type 4 driver.
> Running test org.simplejta.xatests.common.Test1
> autocommit = false
> No of rows Affected 1
> autocommit = false
> No of rows Affected 1
> com.ibm.db2.jcc.b.de: XAER_RMFAIL : Connection is Closed. : Exception from
> native code during XA
> at com.ibm.db2.jcc.uw.UWXAResource.a(UWXAResource.java:695)
> at com.ibm.db2.jcc.uw.UWXAResource.a(UWXAResource.java:709)
> at com.ibm.db2.jcc.uw.UWXAResource.end(UWXAResource.java:227)
> at org.simplejta.xatests.common.Test1.doTest(Test1.java:52)
> at org.simplejta.tests.DB2Tests.main(DB2Tests.java:65)
> Caused by: com.ibm.db2.jcc.b.SqlException: Connection is Closed.
> at com.ibm.db2.jcc.uw.UWXAResource.a(UWXAResource.java:705)
> ... 3 more
> Test org.simplejta.xatests.common.Test1 failed
> Curiously, the error appears to corrupt the database. Subsequent attempts to
> start the database gives an error.
> org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1,
> SQLSTATE: XJ040, SQLERRMC: tcaXJ040.CXSTB0:XSTB0.MFailed to start
>
