Interfacing with embedded derby from an outside process/shell

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Interfacing with embedded derby from an outside process/shell

Dmitry Buzolin
Hi List!

I have a tough problem: My application runs Derby in embedded mode and I have a requirement to change/correct data inside this database.
What is a best way to do this if it is possible? For example if I open this database location via "file://patch to db folder” will this work properly wrt data consistency, locking etc (since the database is accessed from within the app code)?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interfacing with embedded derby from an outside process/shell

kristwaa
Hi Dmitry,

Only one process can open / boot a specific database (usually a set of files on disk) at a given time.
Depending on your requirements you can:
 a) shut down the application and boot the database using any standard JDBC tool (using the embedded driver)
 b) if you need to be able to access the database while the application is running, you need to enable the Derby network server mode and connect to it using the network driver. This can be done in more than one way, for instance by specifying a system property on startup. This may have security implications for your application.

If this is a permanent requirement, it should be possible to start and stop the network server from within your application (i.e. by adding support for this feature in your application). See the Derby Administration guide for more info.


Hope this helps,
-- 
Kristian

ons. 2. aug. 2017 kl. 14:47 skrev Dmitry Buzolin <[hidden email]>:
Hi List!

I have a tough problem: My application runs Derby in embedded mode and I have a requirement to change/correct data inside this database.
What is a best way to do this if it is possible? For example if I open this database location via "file://patch to db folder” will this work properly wrt data consistency, locking etc (since the database is accessed from within the app code)?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interfacing with embedded derby from an outside process/shell

Dmitry Buzolin
Thanks you Kristian,

Booting/opening is clear. But say Derby is booted/opened by an application, can I connect to the same database via IJ tools and interface with the database (UPDATE/INSERT/DELETE)? Or this is not supported? 

On Aug 2, 2017, at 10:39 AM, Kristian Waagan <[hidden email]> wrote:

Hi Dmitry,

Only one process can open / boot a specific database (usually a set of files on disk) at a given time.
Depending on your requirements you can:
 a) shut down the application and boot the database using any standard JDBC tool (using the embedded driver)
 b) if you need to be able to access the database while the application is running, you need to enable the Derby network server mode and connect to it using the network driver. This can be done in more than one way, for instance by specifying a system property on startup. This may have security implications for your application.

If this is a permanent requirement, it should be possible to start and stop the network server from within your application (i.e. by adding support for this feature in your application). See the Derby Administration guide for more info.


Hope this helps,
-- 
Kristian

ons. 2. aug. 2017 kl. 14:47 skrev Dmitry Buzolin <[hidden email]>:
Hi List!

I have a tough problem: My application runs Derby in embedded mode and I have a requirement to change/correct data inside this database.
What is a best way to do this if it is possible? For example if I open this database location via "file://patch to db folder” will this work properly wrt data consistency, locking etc (since the database is accessed from within the app code)?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interfacing with embedded derby from an outside process/shell

kristwaa

No, that is not supported using the embedded driver only.

You either have to shut down the application, or connect using the network driver (while the application itself connects using the embedded driver). The "embedded server mode" is described at [1] and in the admin guide.

Do you need the application to be up while you interface with the database manually?

Regards,
--
Kristian

[1] https://stackoverflow.com/q/374833/4473053


Den ons. 2. aug. 2017, 16:46 skrev Dmitry Buzolin <[hidden email]>:
Thanks you Kristian,

Booting/opening is clear. But say Derby is booted/opened by an application, can I connect to the same database via IJ tools and interface with the database (UPDATE/INSERT/DELETE)? Or this is not supported? 

On Aug 2, 2017, at 10:39 AM, Kristian Waagan <[hidden email]> wrote:

Hi Dmitry,

Only one process can open / boot a specific database (usually a set of files on disk) at a given time.
Depending on your requirements you can:
 a) shut down the application and boot the database using any standard JDBC tool (using the embedded driver)
 b) if you need to be able to access the database while the application is running, you need to enable the Derby network server mode and connect to it using the network driver. This can be done in more than one way, for instance by specifying a system property on startup. This may have security implications for your application.

If this is a permanent requirement, it should be possible to start and stop the network server from within your application (i.e. by adding support for this feature in your application). See the Derby Administration guide for more info.


Hope this helps,
-- 
Kristian

ons. 2. aug. 2017 kl. 14:47 skrev Dmitry Buzolin <[hidden email]>:
Hi List!

I have a tough problem: My application runs Derby in embedded mode and I have a requirement to change/correct data inside this database.
What is a best way to do this if it is possible? For example if I open this database location via "file://patch to db folder” will this work properly wrt data consistency, locking etc (since the database is accessed from within the app code)?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interfacing with embedded derby from an outside process/shell

Dmitry Buzolin
The app can be taken down. I just trying to wrap my head around this scenario, since I am not great in Derby and doc is bit scant for this case.
Ok, so I see the connection via network drive is an option. Does Derby exposes the any listening port when it is started in embedded mode?


On Aug 2, 2017, at 12:45 PM, Kristian Waagan <[hidden email]> wrote:

No, that is not supported using the embedded driver only.

You either have to shut down the application, or connect using the network driver (while the application itself connects using the embedded driver). The "embedded server mode" is described at [1] and in the admin guide.

Do you need the application to be up while you interface with the database manually?

Regards,
--
Kristian

[1] https://stackoverflow.com/q/374833/4473053


Den ons. 2. aug. 2017, 16:46 skrev Dmitry Buzolin <[hidden email]>:
Thanks you Kristian,

Booting/opening is clear. But say Derby is booted/opened by an application, can I connect to the same database via IJ tools and interface with the database (UPDATE/INSERT/DELETE)? Or this is not supported? 

On Aug 2, 2017, at 10:39 AM, Kristian Waagan <[hidden email]> wrote:

Hi Dmitry,

Only one process can open / boot a specific database (usually a set of files on disk) at a given time.
Depending on your requirements you can:
 a) shut down the application and boot the database using any standard JDBC tool (using the embedded driver)
 b) if you need to be able to access the database while the application is running, you need to enable the Derby network server mode and connect to it using the network driver. This can be done in more than one way, for instance by specifying a system property on startup. This may have security implications for your application.

If this is a permanent requirement, it should be possible to start and stop the network server from within your application (i.e. by adding support for this feature in your application). See the Derby Administration guide for more info.


Hope this helps,
-- 
Kristian

ons. 2. aug. 2017 kl. 14:47 skrev Dmitry Buzolin <[hidden email]>:
Hi List!

I have a tough problem: My application runs Derby in embedded mode and I have a requirement to change/correct data inside this database.
What is a best way to do this if it is possible? For example if I open this database location via "file://patch to db folder” will this work properly wrt data consistency, locking etc (since the database is accessed from within the app code)?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interfacing with embedded derby from an outside process/shell

Rick Hillegas-3
Hi Dmitry,

In embedded mode, an application boots the Derby engine by making a JDBC connection. By itself, the embedded engine does not listen on any port for connection requests from other processes. So if your application uses the embedded driver, the engine won't respond to any other process.

In contrast, the Derby network server is a special application which embeds the Derby engine. The network server does listen on a network port. The network server forwards SQL commands to the engine which it embeds.

Hope this helps,
-Rick

On 8/2/17 11:15 AM, Dmitry Buzolin wrote:
The app can be taken down. I just trying to wrap my head around this scenario, since I am not great in Derby and doc is bit scant for this case.
Ok, so I see the connection via network drive is an option. Does Derby exposes the any listening port when it is started in embedded mode?


On Aug 2, 2017, at 12:45 PM, Kristian Waagan <[hidden email]> wrote:

No, that is not supported using the embedded driver only.

You either have to shut down the application, or connect using the network driver (while the application itself connects using the embedded driver). The "embedded server mode" is described at [1] and in the admin guide.

Do you need the application to be up while you interface with the database manually?

Regards,
--
Kristian

[1] https://stackoverflow.com/q/374833/4473053


Den ons. 2. aug. 2017, 16:46 skrev Dmitry Buzolin <[hidden email]>:
Thanks you Kristian,

Booting/opening is clear. But say Derby is booted/opened by an application, can I connect to the same database via IJ tools and interface with the database (UPDATE/INSERT/DELETE)? Or this is not supported? 

On Aug 2, 2017, at 10:39 AM, Kristian Waagan <[hidden email]> wrote:

Hi Dmitry,

Only one process can open / boot a specific database (usually a set of files on disk) at a given time.
Depending on your requirements you can:
 a) shut down the application and boot the database using any standard JDBC tool (using the embedded driver)
 b) if you need to be able to access the database while the application is running, you need to enable the Derby network server mode and connect to it using the network driver. This can be done in more than one way, for instance by specifying a system property on startup. This may have security implications for your application.

If this is a permanent requirement, it should be possible to start and stop the network server from within your application (i.e. by adding support for this feature in your application). See the Derby Administration guide for more info.


Hope this helps,
-- 
Kristian

ons. 2. aug. 2017 kl. 14:47 skrev Dmitry Buzolin <[hidden email]>:
Hi List!

I have a tough problem: My application runs Derby in embedded mode and I have a requirement to change/correct data inside this database.
What is a best way to do this if it is possible? For example if I open this database location via "file://patch to db folder” will this work properly wrt data consistency, locking etc (since the database is accessed from within the app code)?



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interfacing with embedded derby from an outside process/shell

Dmitry Buzolin
Thank you Rick and All, all clear now.
Loading...