Flavio Palumbo wrote:
Hi Michael,
yes, you're right, but I'd like to control the start up of the server from
inside my application, not letting this control to the OS.
Flavio,
Although that can work for specific environments, it is impossible to do
for an arbitrary environment.
A simple example, on my system I could do this to start the server on a
remote machine:
ssh REMOTEHOST -f 'java -Dderby.system.home=/tmp -classpath
/PATH/TO/DERBY/JARS org.apache.derby.drda.NetworkServerControl start &>
/dev/null'
However, this would not work on Mr. Segel's system, for a number of reasons:
- I don't know the hostname/ip of the machine to start the server on
- he might not have the SSH service running
- I don't know which user to log in as
- I have keys on my system, I don't have that on Mr. Segel's
- I don't know where the Derby jars are installed
- Am I allowed to use port 1527?
- What is the layout of the file system? Where do I store the database?
The list could be made *a lot longer*, and there would be a similar list
for all approaches. The message is that you cannot do what you want to
do! You have entered the realm of system administration, and the system
administrator is required to take action to get your software up and
running.
This is not a Derby problem, you will face the same obstacles with any
database system.
Hope this helps,
--
Kristian
Thanks a lot
Flavio
-----Messaggio originale-----
Da: Michael Segel [mailto:[EMAIL PROTECTED] conto di [EMAIL PROTECTED]
Inviato: martedì 1 agosto 2006 14.45
A: 'Derby Discussion'
Oggetto: RE: R: R: connection strange behavior
What you are asking for is to have the database separate from the
applications.
Disregard any sharing of the disk.
Its irrelevant.
The key is that you want anyone on workstation A B or C ... to be able to
connect to the Derby Networked Server sitting on platform X.
If for some reason Derby is not "up", you want to be able to start Derby.
So what you are really asking is for the start up script of Derby to be
embedded as a service to be run during start up.
How to do this will depend on the flavor of the OS. (Windows is different
from Linux which may still be different from the various flavors
of Unix....
Does that now make sense?
-----Original Message-----
From: Flavio Palumbo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 01, 2006 7:08 AM
To: Derby Discussion
Subject: R: R: R: connection strange behavior
Hi Kristian,
you've summarized my scenario very efficiently :-)) ; I've exactly this
envinronment :
there are 3 (or many) workstations (A, B and C ...) and one server (X)
where
resides my application and the derby directory, and both are shared
between
all workstations.
You are right when you say that the centralized server approach is the
right
solution.
Let me add some details :
in a normal scenario (think at Postgres or MySql ...) you first of all
install the db manager, that usually is installed like a
service and thus
is
started at the start up of machine.
I'd like to substitute the db manager with the derby network server,
avoiding, for the user, the work to install it and to have care to start
and
stop it.
Now, thanks to you and everybody answered this mail, I think I can
structure
the problem in this way :
- when my application is started, (workstation A connect to the
server X)
it
verifies if the network server is running
(the ping() method of the NetworkServerControl)
- if not running the application starts the NetworkServerControl in a
separate jvm (don't know how) with a fixed IP
(the server X IP)
- now my application can connect to the derby server using the client
driver
(org.apache.derby.jdbc.ClientDriver)
- when the server X will be shut down the NetworkServerControl will be
closed too.
If you think this approach is right my only dark point is how
to start the
NetworkServerControl in a separate jvm.
Thanks a lot for your hints.
Flavio
-----Messaggio originale-----
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Inviato: martedì 1 agosto 2006 11.20
A: Derby Discussion
Oggetto: Re: R: R: connection strange behavior
Flavio Palumbo wrote:
Hi Stanley,
thanks for your responses ;-))
I looked the links you provided but I think my scenario is
different.
I still don't quite understand the scenario.
Let's say there are 3 workstations (A, B and C) and one server (X).
I think you have a directory/disk on X that is shared between all
workstations.
If you want to access a shared database from A, B and C at the same
time, the most common solution would be to start the Derby network
server on X, and have the applications on the workstations
connect with
the client driver (org.apache.derby.jdbc.ClientDriver).
This would require some management of server X, including
starting/stopping the Derby network server when the machine is
started/shutdown. The Derby network server would always be running as
long as X is running.
*If* Derby were able to operate efficiently and correct when the
database files are stored on a network drive, you would have to handle
the logic of determining if and where the Derby network server is
started. Doing this might require knowledge of all possible clients, a
well-known location to post this information, or maybe a peer-to-peer
architecture.
Maybe I'm a bit dense, but can you please explain why the centralized
server approach won't work for you?
I wrote a stand alone application (like a VB .exe, not WEB)
that is shared
on a local network because the directory where the jars resides
is shared
for all the network users ; inside this directory is defined a derby
database with 2 user tables, and I'd like that the access to
these tables
was shared for all the users that concurrently run the application.
The first time I tried to use the embedded driver, but this way
doesn't
share the database ; thus I tried to implement the network
server making it
start every time a user starts the application but in this way
I found the
problem mentioned in earlier mails.
I think a right way could be start the server once, in a
separate jvm, when
the first time the application is called and then let it up and
running
until the PC is shut down.
What you think about this ??
Here I'm confused again. Do you want to share data between multiple
machines, or only between multiple applications on a single machine?
Another problem is that I don't know how start the server from
inside the
application in a separate jvm.
Could you give some other hints or code snippet ??
You could check if you can connect on specified port. If not,
you assume
the server is down, and that you are responsible for starting it. I'm
sure someone know how to start the server as a separate
process/JVM, but
let us first make sure that is what you want to do :)
Regards,
--
Kristian
Thanks a lot
Flavio
-----Messaggio originale-----
Da: Stanley Bradbury [mailto:[EMAIL PROTECTED]
Inviato: lunedì 31 luglio 2006 21.15
A: Derby Discussion
Oggetto: Re: R: connection strange behavior
Flavio Palumbo wrote:
Hi all,
sorry for the long delay of this response but I spent a little
holiday ;-))
Could you please provide some code examples ?? specially when
you say :
"Usually it is done by defining a global datasource that is
started when
the server starts. Then by setting the property
derby.drda.startNetworkServer to true in the JVM arguments
that are set
at Server startup the Network Server will also start. It is
recommended
that he Network Server be started and shutdown when the server
starts
and shutdowns and also that a security manager be used to
secure the
environment."
Thanks a lot.
Flavio
Flavio Palumbo wrote:
Hi,
thanks everybody for the suggestions provided ;-))
Now I try to explane my goal :
- I have an application shared in a local network
environment (one jar
file
where every client in the network can double
click and start it in a new jvm)
- when the application starts, I'd like to start
(automatically) the derby
network server
- every client opens a new connection to the server
- when the client finishes its work, it closes its own
connection, shut
down
its instance of the application and closes
its jvm
- the last client closes the server
- note that the shared derby DB is in a network shared directory
to achieve the aim explaned above I wrote a test case where I
do something
different : every time the application starts,
it starts a new instance of the network server and a new
connection. I did
this cause I don't know how to start the network server only
once (when
the
first client starts the application) and also don't know
how to be
informed
when the last
client closes the application.
This kind of test seems to work ; if I open the
application in two
different
shells of my PC (two jvm) I can read and write into the same
table of the
same db, thus it seems to be shared as I desire.
But following the tests I encountered some impredictable errors
(not
always
the same error, data seems to be lost, strange exceptions ...)
making me
think maybe this is not the right way :-((
Thanks for any suggestion
Flavio
=== SNIP ========
Hi -
Ouch, You are correct when you say:
" (not always the same error, data seems to be lost, strange
exceptions
...) making me think maybe this is not the right way "
Strange exceptions and data loss is what happens when database I/O
is
performed across a network. Your configuration is causing
these problems:
" - note that the shared derby DB is in a network shared
directory "
The disks must be local to the machine running the Derby engine.
A centralized server architecture will handle this. Start your
server
and the Network server on the machine where the database files
reside
and have the applications connect either to the server
via whatever
protocols it supports or via the Network Server using the client
driver. How you set this up depend on the server you are using.
Usually it is done by defining a global datasource that is
started when
the server starts. Then by setting the property
derby.drda.startNetworkServer to true in the JVM arguments
that are set
at Server startup the Network Server will also start. It is
recommended
that he Network Server be started and shutdown when the server
starts
and shutdowns and also that a security manager be used to
secure the
environment.
HTH
-----------------------------------------------------------
Il presente messaggio non costituisce un impegno contrattuale
tra SILMA S.r.l. ed il destinatario.
Le opinioni ivi espresse sono quelle dell'autore.
SILMA S.r.l. non assume alcuna responsabilita riguardo al
contenuto del presente messaggio.
Il messaggio è destinato esclusivamente al destinatario.
Il contenuto e gli allegati sono da considerarsi di natura
confidenziale
Nel caso abbiate ricevuto il presente messaggio per errore
siete pregati di comunicarlo
alla casella [EMAIL PROTECTED]
I'm not sure of the architecture you are using. My
response assumed
that you were using an Application Server like Geronimo, Tomcat ,
etc.
These each have their own methods for defining Global datasources.
You
can find writeups that contain instructions on doing this
under 'Product
Writeups' on the Apache Derby Resources page:
http://db.apache.org/derby/integrate/index.html#products
If you are writing your own Server and want to add datasource
functionality to it you might want to use the system that Tomcat
uses:
|commons-dbcp| (http://jakarta.apache.org/commons/dbcp/).
Is this what you needed ??
-----------------------------------------------------------
Il presente messaggio non costituisce un impegno contrattuale
tra SILMA S.r.l. ed il destinatario.
Le opinioni ivi espresse sono quelle dell'autore.
SILMA S.r.l. non assume alcuna responsabilita riguardo al
contenuto del presente messaggio.
Il messaggio è destinato esclusivamente al destinatario.
Il contenuto e gli allegati sono da considerarsi di natura
confidenziale
Nel caso abbiate ricevuto il presente messaggio per errore
siete pregati di comunicarlo
alla casella [EMAIL PROTECTED]
-----------------------------------------------------------
Il presente messaggio non costituisce un impegno contrattuale tra SILMA
S.r.l. ed il destinatario.
Le opinioni ivi espresse sono quelle dell'autore.
SILMA S.r.l. non assume alcuna responsabilita riguardo al contenuto del
presente messaggio.
Il messaggio è destinato esclusivamente al destinatario.
Il contenuto e gli allegati sono da considerarsi di natura confidenziale
Nel caso abbiate ricevuto il presente messaggio per errore siete pregati
di comunicarlo
alla casella [EMAIL PROTECTED]
-----------------------------------------------------------
Il presente messaggio non costituisce un impegno contrattuale tra SILMA S.r.l.
ed il destinatario.
Le opinioni ivi espresse sono quelle dell'autore.
SILMA S.r.l. non assume alcuna responsabilita riguardo al contenuto del
presente messaggio.
Il messaggio è destinato esclusivamente al destinatario.
Il contenuto e gli allegati sono da considerarsi di natura confidenziale
Nel caso abbiate ricevuto il presente messaggio per errore siete pregati di
comunicarlo
alla casella [EMAIL PROTECTED]
