You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Ron Olson <ta...@gmail.com> on 2009/06/05 22:51:33 UTC

Multiple instances of an application using same embedded database?

Hi all-

I am writing an application that uses embedded Derby for holding data
that the application collects/creates. It works great, I really like
Derby.

But, there's a problem: multiple application instances. The
application can be launched multiple times and each instance can
potentially create and retrieve data that would be stored/queried from
Derby. The problem is that the second instance fails to run correctly
because the database is locked by the first instance of the
application.

I can't create a Derby server, the application must be zero-setup and
zero-config; the application handles initial database creation, making
the tables, etc.

I've looked and there doesn't seem to be any info on this. Is this
even possible? If not, might anyone know what I might be able to use?
The original version of the program used SQLite, which keeps the
database in the single file. This was nice, but there isn't a pure
Java way to get at a SQLite db, and besides, I like the additional
functionality Derby gives me.

Thanks for any info,

Tacho

Re: Multiple instances of an application using same embedded database?

Posted by Kristian Waagan <Kr...@Sun.COM>.
On Fri, 2009-06-05 at 22:58 +0200, Peter Ondruška wrote:
> Have a look at the archives of this list. It has been discussed
> already that you can use server mode similarly to embedded.
> 
> 
> Your application may try first use existing database as client and if
> fails to connect it may start server.

Hi,

I guess you could have the application try to connect using the embedded
driver first, and if that fails it could assume another application
instance has already booted the Derby database.
In that case, the second instance could fall back to connect using the
client driver (localhost, custom port maybe).

There are multiple issues with this;
 - various race conditions to handle (pausing, retry)
 - the first instance to boot the database must start the server
   (doing this programatically is easy)
 - "failover" and retry logic for handling the case where the first
application shuts down before the second instance
 - even though we try to keep the embedded and client driver fully
compatible, there may be small differences between them
 - you could theoretically make your application instances talk to each
other, such that you can request that a Derby server is started by the
first instance

Depending on the usage pattern of the application, this may get
complicated...

Is it a possibility to boot/create different databases, or does each
instance require access to the same data (i.e. from earlier sessions)?


Cheers,
-- 
Kristian

> 
> 
> Actually your second application instance would benefit from accessing
> as client because of derby server cache.
> 
> On Fri, Jun 5, 2009 at 10:51 PM, Ron Olson <ta...@gmail.com>
> wrote:
>         Hi all-
>         
>         I am writing an application that uses embedded Derby for
>         holding data
>         that the application collects/creates. It works great, I
>         really like
>         Derby.
>         
>         But, there's a problem: multiple application instances. The
>         application can be launched multiple times and each instance
>         can
>         potentially create and retrieve data that would be
>         stored/queried from
>         Derby. The problem is that the second instance fails to run
>         correctly
>         because the database is locked by the first instance of the
>         application.
>         
>         I can't create a Derby server, the application must be
>         zero-setup and
>         zero-config; the application handles initial database
>         creation, making
>         the tables, etc.
>         
>         I've looked and there doesn't seem to be any info on this. Is
>         this
>         even possible? If not, might anyone know what I might be able
>         to use?
>         The original version of the program used SQLite, which keeps
>         the
>         database in the single file. This was nice, but there isn't a
>         pure
>         Java way to get at a SQLite db, and besides, I like the
>         additional
>         functionality Derby gives me.
>         
>         Thanks for any info,
>         
>         Tacho
> 
> 


Re: Multiple instances of an application using same embedded database?

Posted by Peter Ondruška <pe...@gmail.com>.
Have a look at the archives of this list. It has been discussed already that
you can use server mode similarly to embedded.
Your application may try first use existing database as client and if fails
to connect it may start server.

Actually your second application instance would benefit from accessing as
client because of derby server cache.

On Fri, Jun 5, 2009 at 10:51 PM, Ron Olson <ta...@gmail.com> wrote:

> Hi all-
>
> I am writing an application that uses embedded Derby for holding data
> that the application collects/creates. It works great, I really like
> Derby.
>
> But, there's a problem: multiple application instances. The
> application can be launched multiple times and each instance can
> potentially create and retrieve data that would be stored/queried from
> Derby. The problem is that the second instance fails to run correctly
> because the database is locked by the first instance of the
> application.
>
> I can't create a Derby server, the application must be zero-setup and
> zero-config; the application handles initial database creation, making
> the tables, etc.
>
> I've looked and there doesn't seem to be any info on this. Is this
> even possible? If not, might anyone know what I might be able to use?
> The original version of the program used SQLite, which keeps the
> database in the single file. This was nice, but there isn't a pure
> Java way to get at a SQLite db, and besides, I like the additional
> functionality Derby gives me.
>
> Thanks for any info,
>
> Tacho
>