connection strange behavior

[Flavio Palumbo <fl...@fastwebnet.it>]

Hi all,

I wrote a little class, derived from NsSample.java found in D:\db-derby-10.1.2.1-bin\demo\nserverdemo,
to start an embedded server and use it with an embedded client (no embedded
driver but org.apache.derby.jdbc.ClientDriver) fron within a java application,
all in the same JVM.

The first strange thing I found is that if I try to access the data with
the ij utility while the application is running, I receive a messagge like
this :

ERROR XJ040: Failed to start database 'c:\ESQueryProd\derbyDB', see the next
exception for details.
ERROR XSDB6: Another instance of Derby may have already booted the database
C:\ESQueryProd\derbyDB.

Obviously, when I close the application everything goes fine.

I thought that network server shares connection and data, but it seems not
to be true.

How can I do that ?

I found the same behavior starting the application twice from newtwork :
the first application starts correctly, the second freezes until I shut down
the first.

Thanks for any suggetion

Flavio

PS I run with jvm 1.4.2_09 with win XP sp2 and derby 10.1.2.1

Re: connection strange behavior

[Stanley Bradbury <St...@gmail.com>]

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

R: connection strange behavior

[Flavio Palumbo <f....@silmasoftware.com>]

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

> -----Messaggio originale-----
> Da: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> Inviato: mercoledì 19 luglio 2006 18.31
> A: Derby Discussion
> Oggetto: Re: connection strange behavior
>
>
> Flavio Palumbo wrote:
> > Hi all,
> >
> > I wrote a little class, derived from NsSample.java found in
> D:\db-derby-10.1.2.1-bin\demo\nserverdemo,
> > to start an embedded server and use it with an embedded client
> (no embedded
> > driver but org.apache.derby.jdbc.ClientDriver) fron within a
> java application,
> > all in the same JVM.
> >
> > The first strange thing I found is that if I try to access the data with
> > the ij utility while the application is running, I receive a
> messagge like
> > this :
> >
> > ERROR XJ040: Failed to start database 'c:\ESQueryProd\derbyDB',
> see the next
> > exception for details.
> > ERROR XSDB6: Another instance of Derby may have already booted
> the database
> > C:\ESQueryProd\derbyDB.
> >
> > Obviously, when I close the application everything goes fine.
> >
> > I thought that network server shares connection and data, but
> it seems not
> > to be true.
> >
> > How can I do that ?
>
> Hello Flavio,
>
> If I understand you correctly, what you are trying to do should be
> possible. To make sure we are on the same page here, I have written a
> small application that creates two connections to a database:
>   1) I instruct Derby to start the NetworkServer by setting the property
> derby.drda.startNetworkServer = true.
>   2) The first connection creates the database 'testDB' using the
> embedded driver. The network server is also started now.
>   3) The second connection to 'testDB' is created by using the client
> driver.
>   4) I can connect to the same database using ij by specifying the
>      following command (from ij):
>      > connect 'jdbc:derby://localhost/testDB';
>
> Does this demonstrate what you are trying to to?
> You need to have the Derby jars in your classpath when running the
> application (and ij). Which exactly depends on your Derby version.
>
> I think there are variations on how to do this, and I'm sure people will
> let us know if there are easier/better ways to do it.
>
>
> If you have further questions, we'll try to answer them :)
>
>
>
> Regards,
> --
> Kristian
>
> >
> > I found the same behavior starting the application twice from newtwork :
> > the first application starts correctly, the second freezes
> until I shut down
> > the first.
> >
> > Thanks for any suggetion
> >
> > Flavio
> >
> > PS I run with jvm 1.4.2_09 with win XP sp2 and derby 10.1.2.1
> >
> >
>
>


-----------------------------------------------------------
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 segreteria@silmasoftware.com.

Re: connection strange behavior

[Kristian Waagan <Kr...@Sun.COM>]

Flavio Palumbo wrote:
> Hi all,
> 
> I wrote a little class, derived from NsSample.java found in D:\db-derby-10.1.2.1-bin\demo\nserverdemo,
> to start an embedded server and use it with an embedded client (no embedded
> driver but org.apache.derby.jdbc.ClientDriver) fron within a java application,
> all in the same JVM.
> 
> The first strange thing I found is that if I try to access the data with
> the ij utility while the application is running, I receive a messagge like
> this :
> 
> ERROR XJ040: Failed to start database 'c:\ESQueryProd\derbyDB', see the next
> exception for details.
> ERROR XSDB6: Another instance of Derby may have already booted the database
> C:\ESQueryProd\derbyDB.
> 
> Obviously, when I close the application everything goes fine.
> 
> I thought that network server shares connection and data, but it seems not
> to be true.
> 
> How can I do that ?

Hello Flavio,

If I understand you correctly, what you are trying to do should be 
possible. To make sure we are on the same page here, I have written a 
small application that creates two connections to a database:
  1) I instruct Derby to start the NetworkServer by setting the property 
derby.drda.startNetworkServer = true.
  2) The first connection creates the database 'testDB' using the 
embedded driver. The network server is also started now.
  3) The second connection to 'testDB' is created by using the client 
driver.
  4) I can connect to the same database using ij by specifying the
     following command (from ij):
     > connect 'jdbc:derby://localhost/testDB';

Does this demonstrate what you are trying to to?
You need to have the Derby jars in your classpath when running the 
application (and ij). Which exactly depends on your Derby version.

I think there are variations on how to do this, and I'm sure people will 
let us know if there are easier/better ways to do it.


If you have further questions, we'll try to answer them :)



Regards,
-- 
Kristian

> 
> I found the same behavior starting the application twice from newtwork :
> the first application starts correctly, the second freezes until I shut down
> the first.
> 
> Thanks for any suggetion
> 
> Flavio
> 
> PS I run with jvm 1.4.2_09 with win XP sp2 and derby 10.1.2.1
> 
> 

R: R: R: R: connection strange behavior

[Flavio Palumbo <f....@silmasoftware.com>]

Well ... I think I have good material to review my application and to
investigate deeper for a better solution.

Thanks to everybody partecipate at this discussion and for all the
suggestions.

I 'll keep you informed about any development of this topic.

Thanls again.

Flavio

> -----Messaggio originale-----
> Da: Michael Segel [mailto:msegel@segel.com]
> Inviato: martedì 1 agosto 2006 15.57
> A: 'Derby Discussion'
> Oggetto: RE: R: R: R: connection strange behavior
>
>
> Well, it depends on which system I chose to run Derby. ;-)
> (And if I allow ssh to that server. ;-)
>
> Flavio,
>
> I hope that you rethink your over all design and architecture of
> the system.
>
> What seems to cause the most confusion is that you want to allow each copy
> of the application to start/stop the centralized database server.
>
> This by itself doesn't make any sense. I mean, don't get me wrong, you can
> build this solution, however, its neither efficient, nor safe/practical.
>
> If you are creating a service for an enterprise, then you will want it
> available while the enterprise's server is active. Keeping an
> inactive Derby
> alive has very little cost in terms of system resources.
>
> If you are talking about embedding derby in to your application,
> then you're
> asking for something different and you're not going to have a centralized
> server.
>
> A third choice is that you have a copy of Derby embedded in your app and
> also a centralized server that you synch to.
>
> In that case, each app would start/stop their local copy, however the
> centralized copy is up and running all the time.
>
> I would suggest that if this is for a commercial grade
> deployment, that you
> hire a good architect/developer to help you on your design.
>
> -Mike
>
> > -----Original Message-----
> > From: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> > Sent: Tuesday, August 01, 2006 8:07 AM
> > To: Derby Discussion
> > Cc: msegel@segel.com
> > Subject: Re: R: R: R: connection strange behavior
> >
> > 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:msegel@segel.com]Per conto di
> derby@segel.com
> > >> 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:f.palumbo@silmasoftware.com]
> > >>> 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: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> > >>>> 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:Stan.Bradbury@gmail.com]
> > >>>>>> 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 segreteria@silmasoftware.com.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>> 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 segreteria@silmasoftware.com.
> > >>>>>
> > >>>
> > >>> -----------------------------------------------------------
> > >>> 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 segreteria@silmasoftware.com.
> > >
> > >
> > > -----------------------------------------------------------
> > > 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 segreteria@silmasoftware.com.
> > >
>


-----------------------------------------------------------
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 segreteria@silmasoftware.com.

RE: R: R: R: connection strange behavior

[Michael Segel <ms...@segel.com>]

Well, it depends on which system I chose to run Derby. ;-)
(And if I allow ssh to that server. ;-)

Flavio,

I hope that you rethink your over all design and architecture of the system.

What seems to cause the most confusion is that you want to allow each copy
of the application to start/stop the centralized database server.

This by itself doesn't make any sense. I mean, don't get me wrong, you can
build this solution, however, its neither efficient, nor safe/practical.

If you are creating a service for an enterprise, then you will want it
available while the enterprise's server is active. Keeping an inactive Derby
alive has very little cost in terms of system resources. 

If you are talking about embedding derby in to your application, then you're
asking for something different and you're not going to have a centralized
server.

A third choice is that you have a copy of Derby embedded in your app and
also a centralized server that you synch to.

In that case, each app would start/stop their local copy, however the
centralized copy is up and running all the time.

I would suggest that if this is for a commercial grade deployment, that you
hire a good architect/developer to help you on your design.

-Mike

> -----Original Message-----
> From: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> Sent: Tuesday, August 01, 2006 8:07 AM
> To: Derby Discussion
> Cc: msegel@segel.com
> Subject: Re: R: R: R: connection strange behavior
> 
> 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:msegel@segel.com]Per conto di derby@segel.com
> >> 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:f.palumbo@silmasoftware.com]
> >>> 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: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> >>>> 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:Stan.Bradbury@gmail.com]
> >>>>>> 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 segreteria@silmasoftware.com.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> 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 segreteria@silmasoftware.com.
> >>>>>
> >>>
> >>> -----------------------------------------------------------
> >>> 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 segreteria@silmasoftware.com.
> >
> >
> > -----------------------------------------------------------
> > 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 segreteria@silmasoftware.com.
> >

Re: R: R: R: connection strange behavior

[Kristian Waagan <Kr...@Sun.COM>]

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:msegel@segel.com]Per conto di derby@segel.com
>> 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:f.palumbo@silmasoftware.com]
>>> 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: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
>>>> 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:Stan.Bradbury@gmail.com]
>>>>>> 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 segreteria@silmasoftware.com.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> 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 segreteria@silmasoftware.com.
>>>>>
>>>
>>> -----------------------------------------------------------
>>> 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 segreteria@silmasoftware.com.
> 
> 
> -----------------------------------------------------------
> 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 segreteria@silmasoftware.com.
> 

RE: R: R: connection strange behavior

["Thomas J. Taylor" <th...@itqa.miami.edu>]

Hi Flavio,

If you decide that you want to start-up Derby with the OS, on Windows, I've
used Java Service Launcher (JSL) for the past couple years (see links
below).  

Regards,

Thomas

http://www.roeschter.com/index.html 

http://sourceforge.net/projects/jslwin/

-----Original Message-----
From: Flavio Palumbo [mailto:f.palumbo@silmasoftware.com] 
Sent: Tuesday, August 01, 2006 8:48 AM
To: Derby Discussion; msegel@segel.com
Subject: R: R: R: connection strange behavior

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.

Thanks a lot
Flavio

> -----Messaggio originale-----
> Da: Michael Segel [mailto:msegel@segel.com]Per conto di 
> derby@segel.com
> 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:f.palumbo@silmasoftware.com]
> > 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: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> > > 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:Stan.Bradbury@gmail.com]
> > > >> 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 segreteria@silmasoftware.com.
> > > >>>
> > > >>>
> > > >>>
> > > >> 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 segreteria@silmasoftware.com.
> > > >
> > >
> >
> >
> > -----------------------------------------------------------
> > 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 segreteria@silmasoftware.com.
>


-----------------------------------------------------------
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 segreteria@silmasoftware.com.

R: R: R: connection strange behavior

[Flavio Palumbo <f....@silmasoftware.com>]

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.

Thanks a lot
Flavio

> -----Messaggio originale-----
> Da: Michael Segel [mailto:msegel@segel.com]Per conto di derby@segel.com
> 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:f.palumbo@silmasoftware.com]
> > 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: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> > > 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:Stan.Bradbury@gmail.com]
> > > >> 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 segreteria@silmasoftware.com.
> > > >>>
> > > >>>
> > > >>>
> > > >> 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 segreteria@silmasoftware.com.
> > > >
> > >
> >
> >
> > -----------------------------------------------------------
> > 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 segreteria@silmasoftware.com.
>


-----------------------------------------------------------
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 segreteria@silmasoftware.com.

RE: R: R: connection strange behavior

[de...@segel.com]

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:f.palumbo@silmasoftware.com]
> 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: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> > 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:Stan.Bradbury@gmail.com]
> > >> 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 segreteria@silmasoftware.com.
> > >>>
> > >>>
> > >>>
> > >> 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 segreteria@silmasoftware.com.
> > >
> >
> 
> 
> -----------------------------------------------------------
> 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 segreteria@silmasoftware.com.

R: R: R: connection strange behavior

[Flavio Palumbo <f....@silmasoftware.com>]

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: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM]
> 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:Stan.Bradbury@gmail.com]
> >> 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 segreteria@silmasoftware.com.
> >>>
> >>>
> >>>
> >> 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 segreteria@silmasoftware.com.
> >
>


-----------------------------------------------------------
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 segreteria@silmasoftware.com.

Re: R: R: connection strange behavior

[Kristian Waagan <Kr...@Sun.COM>]

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:Stan.Bradbury@gmail.com]
>> 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 segreteria@silmasoftware.com.
>>>
>>>
>>>
>> 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 segreteria@silmasoftware.com.
> 

R: R: connection strange behavior

[Flavio Palumbo <f....@silmasoftware.com>]

Hi Stanley,

thanks for your responses ;-))

I looked the links you provided but I think my scenario is different.

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 ??

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 ??

Thanks a lot
Flavio


> -----Messaggio originale-----
> Da: Stanley Bradbury [mailto:Stan.Bradbury@gmail.com]
> 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 segreteria@silmasoftware.com.
> >
> >
> >
> 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 segreteria@silmasoftware.com.

Re: R: connection strange behavior

[Stanley Bradbury <St...@gmail.com>]

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 segreteria@silmasoftware.com.
>
>
>   
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 ??

R: connection strange behavior

[Flavio Palumbo <f....@silmasoftware.com>]

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 segreteria@silmasoftware.com.

Re: connection strange behavior

[Stanley Bradbury <St...@gmail.com>]

Flavio Palumbo wrote:
> Hi all,
>
> I wrote a little class, derived from NsSample.java found in D:\db-derby-10.1.2.1-bin\demo\nserverdemo,
> to start an embedded server and use it with an embedded client (no embedded
> driver but org.apache.derby.jdbc.ClientDriver) fron within a java application,
> all in the same JVM.
>
> The first strange thing I found is that if I try to access the data with
> the ij utility while the application is running, I receive a messagge like
> this :
>
> ERROR XJ040: Failed to start database 'c:\ESQueryProd\derbyDB', see the next
> exception for details.
> ERROR XSDB6: Another instance of Derby may have already booted the database
> C:\ESQueryProd\derbyDB.
>
> Obviously, when I close the application everything goes fine.
>
> I thought that network server shares connection and data, but it seems not
> to be true.
>
> How can I do that ?
>
> I found the same behavior starting the application twice from newtwork :
> the first application starts correctly, the second freezes until I shut down
> the first.
>
> Thanks for any suggetion
>
> Flavio
>
> PS I run with jvm 1.4.2_09 with win XP sp2 and derby 10.1.2.1
>
>
>
>   
Hi Flavio -

Be sure you are specifying a Client driver URL in IJ.  For example 
syntax see my response to your post with the Subject line: 'network 
server not shares access'.