Re: Class loading deadlock
On Tue, 2005-09-20 at 10:20 -0700, Daniel John Debrunner wrote: The changes Knut pointed out have been merged to 10.1. If you can build the 10.1 branch and try them out that would be great, otherwise you could wait for a snapshot and try that out. Daniel, the version on the 10.1 branch doesn't deadlock with the testcase, I've had it running for about half an hour now. Thanks for the info. Best regards, Andreas
Re: derby.drda.startNetworkServer property
[EMAIL PROTECTED] writes:
Hi Knut,
Thanks for your quick response.
Then, how can I verify whether Derby, started using
derby.drda.startNetworkServer=true and org.apache.derby.jdbc.EmbeddedDriver,
is ready or not to accept clients like NetworkServerControl#ping() ?
Haven't tested, but I think the following should work:
NetworkServerControl nsc = new NetworkServerControl(address, port);
try {
nsc.ping();
System.out.println(started);
} catch (Exception e) {
System.out.println(not started);
}
--
Knut Anders
Re: derby performance and 'order by'
Rick Hillegas wrote: It might help to add another column to the index so that it covers both the restriction and the ordering information. And if we could add a primary key to a temporary table, then something like the following might take us in the right direction: create index time_index on orders( time, orderID ); declare global temporary table session.ztemp ( orderID varchar( 50 ) primary key ) not logged; -- all the information we need is in the index so there's no need -- to probe the base table insert into session.ztemp select orderID from orders where time between '10/01/2002' and '11/30/2002' ; -- hopefully the temporary table didn't have to spill to disk. -- no sort should be needed for this query and you can just -- stop siphoning out rows after you get the first 1000. select l.* from orders l, session.ztemp r where l.orderID = r.orderID order by orderID; If I understand this correctly, you're here relying on the fact that the primary key constraint on the temporary table creates an underlying index, so the records inserted can be read out in sorted order. This is also a form of sorting. Shouldn't the engine be able to use similar techniques in the execution of the original query, without relying on the user splitting up the query, creating temporary tables etc.? -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
embeddedServer vs NetworkServer: any differences in terms of provileges
hi, I used to spawn a networkserver that I access through JDBC. I have to change my design to a Embedded Server. I have now a PriviledgeActionException (on client side) when opening socket to the server do you have any clue? -- Xavier VIGOUROUX - sun microsystems
Re: embeddedServer vs NetworkServer: any differences in terms of provileges
XV == Xavier Vigouroux [EMAIL PROTECTED] writes: XV hi, XV I used to spawn a networkserver that I access through JDBC. XV I have to change my design to a Embedded Server. XV I have now a PriviledgeActionException (on client side) when opening XV socket to the server XV do you have any clue? Are you starting the network server by setting the derby.drda.startNetworkServer property in the embedded server? Are the client running on another computer than the server? If yes, you need to enable connection from other computers. This is disabled by default for security reasons. You can open for connections from other computers by setting the property derby.drda.host=0.0.0.0. -- Øystein
Re: derby performance and 'order by'
SAD == Suavi Ali Demir [EMAIL PROTECTED] writes: SAD Another little detail about optimization is that SAD Statement.setMaxRows() kind of functions on the JDBC side may SAD not be sufficient since it is called after SQL statement is SAD prepared and returned as an object (after query plan is SAD built). Therefore, it may be necessary to have language SAD syntax to indicate the intention to fetch first 1000 rows SAD only, so that when the query is prepared, this intention can SAD be taken into account. It would be much better if this could be changed at execute-time for an already prepared statement. That is, the same prepared statement could be used regardless of how many rows one is going to fetch. -- Øystein
Re: derby performance and 'order by'
I agree with Øystein, given that the standard JDBC api for the maximum rows is Statement.setMaxRows then Derby should be able to take advantage of that regardless of when it is set. This doesn't imply that a plan gets reprepared, though that could be a solution, it could be implemented as a plan that is flexible enough to handle an optional max rows. Dan. Suavi Ali Demir wrote: Yes, good idea, but if execution plan is going to be different it beats the purpose of being prepared. When it's prepared it gets compiled into bytecode, and different bytecode could be generated for different cases. Some databases do have the sql syntax to fetch first n rows only or limit n for example (i don't know if they can be parametric). Since they have incorporated this functionality, perhaps they have thought these details. I would even imagine that facilities which make this kind of optimization may be available or feasible to use at prepare time but not execute time. Ali */Øystein Grøvlen [EMAIL PROTECTED]/* wrote: SAD == Suavi Ali Demir writes: SAD Another little detail about optimization is that SAD Statement.setMaxRows() kind of functions on the JDBC side may SAD not be sufficient since it is called after SQL statement is SAD prepared and returned as an object (after query plan is SAD built). Therefore, it may be necessary to have language SAD syntax to indicate the intention to fetch first 1000 rows SAD only, so that when the query is prepared, this intention can SAD be taken into account. It would be much better if this could be changed at execute-time for an already prepared statement. That is, the same prepared statement could be used regardless of how many rows one is going to fetch. -- Øystein
Re: derby performance and 'order by'
Hi Oyvind, I agree that this is inelegant. As you note, this approach step by step forces a plan which the current Derby optimizer is capable of considering--with or without the covering index. Regardless of whether we teach the optimizer some better tricks, I think it's worth beefing up our support for in-memory temporary tables: o There are always deceptively simple queries which the optimizer misjudges. It's good to give the customer tools for getting unstuck while they wait for the bugfix release. o Often the customer knows facts about the data which the optimizer can't plausibly learn. o The current Derby optimizer is capable of considering only a very limited subset of the useful plans. Cheers, -Rick [EMAIL PROTECTED] wrote: Rick Hillegas wrote: It might help to add another column to the index so that it covers both the restriction and the ordering information. And if we could add a primary key to a temporary table, then something like the following might take us in the right direction: create index time_index on orders( time, orderID ); declare global temporary table session.ztemp ( orderID varchar( 50 ) primary key ) not logged; -- all the information we need is in the index so there's no need -- to probe the base table insert into session.ztemp select orderID from orders where time between '10/01/2002' and '11/30/2002' ; -- hopefully the temporary table didn't have to spill to disk. -- no sort should be needed for this query and you can just -- stop siphoning out rows after you get the first 1000. select l.* from orders l, session.ztemp r where l.orderID = r.orderID order by orderID; If I understand this correctly, you're here relying on the fact that the primary key constraint on the temporary table creates an underlying index, so the records inserted can be read out in sorted order. This is also a form of sorting. Shouldn't the engine be able to use similar techniques in the execution of the original query, without relying on the user splitting up the query, creating temporary tables etc.?
Can you use createFrom to create a database from a backup database stored in a JAR file?
Hello,
I wasn't sure if this was going to work or not. There was nothing in the documentation to suggest it would, I was just hopeful. I tried searching the archives for createFrom but only got one hit, so I hope this is not a repeat question.
I am attempting to create a writable database from a read only database in a JAR file. The idea is to have a clickable JAR file that can determine if an external database exists, and if not, creates it from an original (not blank) database stored within the JAR file. A code snippet follows:
// Connect to the database
try
{
Class.forName( org.apache.derby.jdbc.EmbeddedDriver ).newInstance(); //Start up derby
}
catch( Exception e )
{
e.printStackTrace();
throw new RuntimeException( e );
}
String databaseUri = PreferenceController.Instance().getPreferenceDirectory().getAbsolutePath() +
java.io.File.separatorChar + vEat;
try
{
// Check to see if the database exists
java.io.File database = new java.io.File( databaseUri );
if( !database.exists() )
{
databaseUri = jdbc:derby: + databaseUri;
System.out.println( Attempting to create database: + databaseUri );
// Database does not exist. Copy the default to the preference directory
Connection conn = DriverManager.getConnection( databaseUri +
;createFrom=/org/vinca/vEat/database/vEat );
conn.close();
}
}
catch( SQLException e )
{
// Couldn't access the database.
(Please excuse my poorly named databaseUri variable...)
The JAR file does include the database, I checked.
I get the following output (some stack removed):
Attempting to create database: jdbc:derby:/Users/michaelj/Library/Preferences/vEat/vEat
SQL Exception: Failed to start database '/Users/michaelj/Library/Preferences/vEat/vEat', see the next exception for details.
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
…
ERROR XBM0Y: Backup database directory /org/vinca/vEat/database/vEat not found. Please make sure that the specified backup path is right.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.services.monitor.PersistentServiceImpl.recreateServiceRoot(Unknown Source)
…
Exception in thread main java.lang.RuntimeException: SQL Exception: Backup database directory /org/vinca/vEat/database/vEat not found. Please make sure that the specified backup path is right.
at org.vinca.vEat.controller.IdMapper.init>(IdMapper.java:62)
…
Caused by: SQL Exception: Backup database directory /org/vinca/vEat/database/vEat not found. Please make sure that the specified backup path is right.
…
So I assume that my attempt is not supported by Derby. Can anyone confirm? Also, anyone have any alternate suggestions on how to accomplish creating a single JAR that can use a pre-made, but writable, database?
Thank you,
Mike Vinca
derby wiki
The new derby wiki is here: http://wiki.apache.org/db-derby Please post questions/issues about the derby wiki to the derby list. I updated wiki.apache.org/general and wiki.apache.org/db to include the new derby wiki. On the db wiki I discovered a link to searchable db archives: http://www.nabble.com/Apache-Database-f105.html regards, -jean
Re: Can you use createFrom to create a database from a backup database stored in a JAR file?
Hi Michael,
I'm not sure I understand the problem you're wrestling with. Forgive me
if I have garbled your message. It sounds as though you want to be able
to create an empty database from a template database. This is pretty
easy to do with Derby:
1) Nest another jar file inside your application jar file. The nested
jar file contains the template database.
2) At runtime, unjar your template database to the directory identified
by the Derby startup property derby.system.home. If you didn't set this
property when starting Derby, then it defaults to be the directory in
which you started the VM.
3) Rename the unjarred subdirectory to be the name you want to use for
the new database.
That should do it.
I hope this addresses your question.
Cheers,
-Rick
Michael Vinca wrote:
Hello,
I wasn't sure if this was going to work or not. There was nothing in
the documentation to suggest it would, I was just hopeful. I tried
searching the archives for createFrom but only got one hit, so I
hope this is not a repeat question.
I am attempting to create a writable database from a read only
database in a JAR file. The idea is to have a clickable JAR file that
can determine if an external database exists, and if not, creates it
from an original (not blank) database stored within the JAR file. A
code snippet follows:
// Connect to the database
try
{
Class.forName( org.apache.derby.jdbc.EmbeddedDriver ).newInstance();
//Start up derby
}
catch( Exception e )
{
e.printStackTrace();
throw new RuntimeException( e );
}
String databaseUri =
PreferenceController.Instance().getPreferenceDirectory().getAbsolutePath()
+
java.io.File.separatorChar + vEat;
try
{
// Check to see if the database exists
java.io.File database = new java.io.File( databaseUri );
if( !database.exists() )
{
databaseUri = jdbc:derby: + databaseUri;
System.out.println( Attempting to create database: + databaseUri );
// Database does not exist. Copy the default to the preference directory
Connection conn = DriverManager.getConnection( databaseUri +
;createFrom=/org/vinca/vEat/database/vEat );
conn.close();
}
}
catch( SQLException e )
{
// Couldn't access the database.
(Please excuse my poorly named databaseUri variable...)
The JAR file does include the database, I checked.
I get the following output (some stack removed):
Attempting to create database:
jdbc:derby:/Users/michaelj/Library/Preferences/vEat/vEat
SQL Exception: Failed to start database
'/Users/michaelj/Library/Preferences/vEat/vEat', see the next
exception for details.
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
…
ERROR XBM0Y: Backup database directory /org/vinca/vEat/database/vEat
not found. Please make sure that the specified backup path is right.
at org.apache.derby.iapi.error.StandardException.newException(Unknown
Source)
at
org.apache.derby.impl.services.monitor.PersistentServiceImpl.recreateServiceRoot(Unknown
Source)
…
Exception in thread main java.lang.RuntimeException: SQL Exception:
Backup database directory /org/vinca/vEat/database/vEat not found.
Please make sure that the specified backup path is right.
at org.vinca.vEat.controller.IdMapper.init(IdMapper.java:62)
…
Caused by: SQL Exception: Backup database directory
/org/vinca/vEat/database/vEat not found. Please make sure that the
specified backup path is right.
…
So I assume that my attempt is not supported by Derby. Can anyone
confirm? Also, anyone have any alternate suggestions on how to
accomplish creating a single JAR that can use a pre-made, but
writable, database?
Thank you,
Mike Vinca
Distributed databases
Hi, I'm fairly new to Derby but I was curious if its possible to use it in a distributed setup. I currently have a small cluster and want to set it up so that I have a distributed database on it using Derby. So my questions are:1) Is this possible?2) Is there a resource that shows me how to do this? (the manuals don't seem to explain how to do this)3) From what I've read it seems like I need to use the DB2 driver to do this (like I've said, I've found very little info on the subject of setting up a distributed database). Is this even remotely on base?4) Does anyone know of any decent tutorials when it comes to Derby? I haven't found anything that great thus far.5) Can I use ij to manipulate a distributed database? How do I do this?6) Is there a way to setup one using ij?Sorry for all of the questions but I've searched through a couple hundred websites while searching on google and have found little to no info. Thanks in advance for any help.Andy
