Controlling Cloudscape Application Behavior
Page 5 of 7

Working with Multiple Connections to a Single Database

Deployment Options and Threading and Connection Modes

A database can be available to multiple connections in the following situations:

  • Multiple applications access a single database (possible only when Cloudscape is running inside a server framework).
  • A single application has more than one Connection to the same database.

The way you deploy Cloudscape affects the ways applications can use multi-threading and connections, as shown in Table 6-6.

Table 6-6 Threading and Connection Modes 


Embedded

Server

Multi-Threaded

From an application, using a single Connection to a Cloudscape database and issuing requests against that connection in multiple threads.

Supply a single Connection object to separate threads. Cloudscape ensures that only one operation is applied at a time for consistency.

Note that committing a transaction commits all statements open against a single connection. For more information, see Transactions.

Server frameworks such as Cloudconnector and RmiJdbc can automatically multi-thread operations. Allowing Cloudconnector to multi-thread does not affect transaction control, which is handled by the source application.

Remote client applications can multi-thread if desired.

Multi-Connection

From an application, using multiple connections to a Cloudscape database and issuing requests against those connections on multiple threads.

(You must have a multi-user license to have more than one connection to Cloudscape.)

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 Cloudscape system.

Cloudconnector and RmiJdbc always manage multiple connections.

Remote client applications can establish the multiple connections desired.

Multi-User

Multiple applications accessing the same Cloudscape 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.

In the current release, Cloudscape may not prevent multiple applications from concurrently accessing the same Cloudscape 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.

Multi-User Database Access

Multi-user database access is possible if Cloudscape is running inside a server framework.

If more than one client application tries to modify the same data, the application that gets the table first gets the lock on the data (either specific rows or the entire table). The second application has to wait until the first application commits or rolls back the transaction in order to access the data. If two applications are only querying and not modifying data, they can both access the same data at the same time because they can each get a shared lock. For more information, see Locking, Concurrency, and Isolation.

Multiple Connections from a Single Application

A single application can work with multiple Connections to the same database and assign them to different threads. The application programmer can avoid concurrency and deadlock problems in several ways:

  • Use the READ_COMMITTED isolation level and turn on row-level locking (the defaults).
  • Beware of deadlocks caused by using more than one Connection in a single thread (the most obvious case). For example, if the thread tries to update the same table from two different Connections, a deadlock can occur.
  • Assign Connections to threads that handle discrete tasks. For example, do not have two threads update the Hotels table. Have one thread update the Hotels table and a different one update the Groups table.
  • If threads access the same tables, commit transactions often.
  • Multi-threaded Java applications have the ability to self-deadlock without even accessing a database, so beware of that too.
  • Use nested connections to share the same lock space.