Re: Another newbie internals question
Daniel John Debrunner wrote: Frank Griffin wrote: Kathey Marsden wrote: Frank Griffin wrote: get-go (of course, how you could open JDBC access without actually opening JDBC access is a bit of a conundrum). Any ideas or direction ? You could connect with the embedded driver to do your initial setup before starting network server and letting clients in. I gave this a try, and almost got it to work. My code does its initial setup by loading the embedded driver and submitting CREATE FUNCTION statements, and that works fine. When it's done, it tries to turn control over to the Network Server. The problem is, the Network Server returns immediately, the app returns, and the JVM shuts down. I think the jvm is exiting because your are returning from your java main method before the network server gets a chance to start its thread. Thanks for the reply, but I think that the difference is that NetworkServerControl.main() calls the executeWork() method, while NetworkServerControl.start() does not. The docs say that users of an embedded NetworkServerControl are supposed to call start().
Re: Another newbie internals question
Kathey Marsden wrote:
Frank Griffin wrote:
get-go (of course, how you could open JDBC access without actually
opening JDBC access is a bit of a conundrum).
Any ideas or direction ?
You could connect with the embedded driver to do your initial setup
before starting network server and letting clients in.
I gave this a try, and almost got it to work. My code does its initial
setup by loading the embedded driver and submitting CREATE FUNCTION
statements, and that works fine. When it's done, it tries to turn
control over to the Network Server. The problem is, the Network Server
returns immediately, the app returns, and the JVM shuts down.
In the code below, the NOMADDerbyUpdateQueries class does the initial
setup, and should then execute periodically to see if any new queries
(Table Functions) have been dropped into its directory (hence the
timer.schedule() and timer.cancel()).
Is there a way to get the Network Server to block until it is told to
shut down ? If not, is there a way to query the status of the Network
Server, so that I can wait in a timed loop until I detect that it's been
stopped ?
derby.log at the end of this has:
2008-01-25 16:52:13.569 GMT:
Booting Derby version The Apache Software Foundation - Apache Derby -
10.4.0.0 alpha - (614553): instance c013800d-0117-b1dd-1b95-0f6f8d10
on database directory /data/ftg/tmp/derbyhome/data/NOMAD
Database Class Loader started - derby.database.classpath=''
Apache Derby Network Server - 10.4.0.0 alpha - (614553) started and
ready to accept connections on port 1527 at 2008-01-25 16:52:14.730 GMT
The code is:
public static
void
main( String[] args )
throws Exception
{
NOMADDerbyUpdateQueriesoUpdate;
NetworkServerControl oServer;
Timer timer;
oUpdate = new NOMADDerbyUpdateQueries();
oUpdate.run();
timer = new Timer( true );
timer.schedule( oUpdate,
0L,
1L );
if ( args.length 0 )
{
InetAddress ia = InetAddress.getByName( localhost );
oServer = new NetworkServerControl
( ia,
Integer.parseInt( args[0] ) );
}
else
{
oServer = new NetworkServerControl();
}
oServer.start( new PrintWriter( System.out ) );
timer.cancel();
return;
}
Thanks again,
Frank
Re: Another newbie internals question
Frank Griffin wrote: Kathey Marsden wrote: Frank Griffin wrote: get-go (of course, how you could open JDBC access without actually opening JDBC access is a bit of a conundrum). Any ideas or direction ? You could connect with the embedded driver to do your initial setup before starting network server and letting clients in. I gave this a try, and almost got it to work. My code does its initial setup by loading the embedded driver and submitting CREATE FUNCTION statements, and that works fine. When it's done, it tries to turn control over to the Network Server. The problem is, the Network Server returns immediately, the app returns, and the JVM shuts down. I think the jvm is exiting because your are returning from your java main method before the network server gets a chance to start its thread. The javadoc for NetworkServerControl.start() indicates one can ping the server to check when it is ready: http://db.apache.org/derby/javadoc/publishedapi/jdbc3/org/apache/derby/drda/NetworkServerControl.html#start(java.io.PrintWriter) Dan.
Another newbie internals question
I want to bring up a captive instance of Derby as a JDBC server. I want to do this using a front class of my own, because I want to customize the environment somewhat (set a few system properties, load and launch a few custom classes, whatever). This should all a simple thing, just wrapping the normal Derby invocation class; here's the kicker: once Derby is initialized, I want to initiate a JDBC session with it and submit a series of customizing SQL statements (CREATE FUNCTIONs for Table Functions). Modifying Derby code is OK for this, but I'd rather keep modifications to a minimum. Is there a clean way to do this other than starting a Thread which attempts JDBC connect() until Derby is ready ? Basically, I need to hook into someplace in Derby once it is enabled for JDBC in order to force-feed some commands before the real clients come along, so that the TableFunctions I'm setting up will be available for them. I don't really care if users are locked out before these things are processed; I can live with telling people just let it come up fully, but of course it would be nice to ensure availability from the get-go (of course, how you could open JDBC access without actually opening JDBC access is a bit of a conundrum). Any ideas or direction ? Thanks, Frank Griffin
Re: Another newbie internals question
Hi Frank, You might be able to accomplish what you need by doing the following: 1) Bring up the server with user authentication turned on, with derby.database.defaultConnectionMode set to noAccess, and with derby.database.fullAccess set to be the name of your database owner. This should lock out everyone except for the database owner. 2) Then connect as the database owner, create your database, and initialize it with your functions, other schema objects, and data. 3) Then set derby.database.defaultConnectionMode to fullAccess and unset derby.database.fullAccess. This should allow the other users in. I say might because I haven't tried this experiment. These properties along with authentication are discussed in the Derby Developer's Guide in the sections titled User authorizations and Working with user authentication. Hope this helps, -Rick Frank Griffin wrote: I want to bring up a captive instance of Derby as a JDBC server. I want to do this using a front class of my own, because I want to customize the environment somewhat (set a few system properties, load and launch a few custom classes, whatever). This should all a simple thing, just wrapping the normal Derby invocation class; here's the kicker: once Derby is initialized, I want to initiate a JDBC session with it and submit a series of customizing SQL statements (CREATE FUNCTIONs for Table Functions). Modifying Derby code is OK for this, but I'd rather keep modifications to a minimum. Is there a clean way to do this other than starting a Thread which attempts JDBC connect() until Derby is ready ? Basically, I need to hook into someplace in Derby once it is enabled for JDBC in order to force-feed some commands before the real clients come along, so that the TableFunctions I'm setting up will be available for them. I don't really care if users are locked out before these things are processed; I can live with telling people just let it come up fully, but of course it would be nice to ensure availability from the get-go (of course, how you could open JDBC access without actually opening JDBC access is a bit of a conundrum). Any ideas or direction ? Thanks, Frank Griffin
Re: Another newbie internals question
Frank Griffin wrote: get-go (of course, how you could open JDBC access without actually opening JDBC access is a bit of a conundrum). Any ideas or direction ? You could connect with the embedded driver to do your initial setup before starting network server and letting clients in. Kathey
