A database can be available to multiple connections in several situations.
The way you deploy Derby affects the ways applications can use multi-threading and connections, as shown in the following table.
| Connection Mode | Embedded | Server |
|---|---|---|
| Multi-Threaded From an application, using a single Connection to a Derby database and issuing requests against that connection in multiple threads. |
Supply a single Connection object to separate threads. Derby ensures that only one operation is applied at a time for consistency. Server frameworks automatically manage multi-threaded operations. | Server frameworks can automatically multi-thread operations. Remote client applications can multi-thread if desired. |
| Multi-Connection From an application, using multiple connections to a Derby database and issuing requests against those connections on multiple threads. |
Create individual connections within a single application and use the appropriate connection for each JDBC request. The connections can all be to the same database, or can be to different databases in the same Derby system. | Remote client applications can establish the multiple connections desired. |
| Multi-User Multiple applications (or JVMs) accessing the same Derby database. Each user application has its own connection or connections to the database. |
Not possible. Only one application can access a database at a time, and only one application can access a specific system at a time. If Derby is running on a small device platform and presenting the JSR 169 interface to clients, it might not prevent multiple applications from concurrently accessing the same Derby system, but do not allow this because such access can corrupt the databases involved. | Only one server should access a database at a time. Multiple remote client applications can access the same server, and thus can access the same database at the same time through that server. |