db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Linehan <lineh...@tcd.ie>
Subject Embedded - can it be multi-user?
Date Sun, 03 Jul 2011 03:59:42 GMT
Hi all,

I've just started to use Derby and really like it. I've come from
a Firebird embedded environment with Java, but the
fact that Derby is written in Java is a decisive factor
in its favour - its feature set is also impressive.

However, there's one thing that's confusing me. First thing I did
was go to the "getstartderby.pdf" docco and go through the
tutorial. All worked fine, however I was confused by this bit

(End of page 33, start of 34)
Derby's two architectures have caused confusion for some new Derby
users, who mistakenly think that embedded is a single-user
configuration. This is not true. The embedded driver supports multiple
simultaneous connections, performs locking, and provides performance,
integrity, and recoverability. Any application that uses the Getting Started
with Derby embedded driver can open multiple Derby connections and
then provide a means for multiple users to interact with the database
on each connection.
The Derby Network Server is an example of such an application.

Now, I was using the SQuirreL SQL Client to look at my databases
as they were being created, but I couldn't use ij with the database
*_and_* SQuirreL at the same time.

What I'm wondering is, if there's a single app connecting to the database
multiple times, is it up to the app to manage the connections so that
only one connection is active at any one time, or how exactly does that
work? Say in a context where an App Server is connecting to an embedded
Derby database - i.e. no server running - does the App Server have to manage
requests to the database in a queue or how, exactly does the system work?

TIA for any pointers, tips, clues, references, URL's or anything else useful.





Mob: 00 353 86 864 5772

View raw message