You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Frank Griffin <ft...@roadrunner.com> on 2008/01/22 23:18:47 UTC
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
Posted by Frank Griffin <ft...@roadrunner.com>.
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
Posted by Daniel John Debrunner <dj...@apache.org>.
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.
Re: Another newbie internals question
Posted by Frank Griffin <ft...@roadrunner.com>.
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-00000f6f8d10
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
{
NOMADDerbyUpdateQueries oUpdate;
NetworkServerControl oServer;
Timer timer;
oUpdate = new NOMADDerbyUpdateQueries();
oUpdate.run();
timer = new Timer( true );
timer.schedule( oUpdate,
0L,
10000L );
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
Posted by Kathey Marsden <km...@sbcglobal.net>.
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
Re: Another newbie internals question
Posted by Rick Hillegas <Ri...@Sun.COM>.
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
>