Basic Concepts

It is very important to make a distinction between Zim 9 Server and Zim Server Connectivity.

Zim 9 Server always operates in Client/Server mode where Zim Server is the server and Zim, Zim Thin Client are the clients. The clients run a Zim application that accesses data provided by the server. Every time a client session is started, some parameters are provided to allow an automatic connection to Zim 9 Server thus allowing the interaction between the client and the server to occurs normally. One of the parameters provided is the name of the database to which the client wants to connect to. From this point on, all references to data will be automatically directed to this specific database and only to this specific database. This interaction remains active until the client ends its operation.

However, it is possible that – as required by the application – to access data from another database either serviced by the current Zim Server or by another Zim Server running in a different machine. In this case, it is needed a Zim Server Connectivity,  where this very same client now has to connect to this second database, has to perform some data processing and eventually has to disconnect from this second database. All this activity happens while the client is running and, therefore, still connected to the original database.

If also needed by the application, another Zim Server Connectivity can be performed with a third or fourth databases, either at same time or not.

The following flow demonstrates this idea. The ZIM executable is ran passing the parameter to connect to database named “Original”:

ZIM starts its execution

automatically connects to database “Original”;

…

CONNECT TO a second database called “Second”;

…

DISCONNECT FROM “Second”;

…

CONNECT TO a second database called “Second”;

CONNECT TO a third database called “Third”;

…

DISCONNECT FROM “Second”;

DISCONNECT FROM “Third”;

…

automatically disconnects from “Original”

ZIM ends its execution

This example shows that, after the ZIM executable is started, an explicit CONNECT to “Second” is issued, some processing is accomplished and then a DISCONNECT from “Second” is sent. Later, “Second” and “Third” are connected, processed and disconnected. These two connections are concurrent and must follow the rules described in the note below.

For all purposes, this ZIM session (it can also be Zim Thin Client) is a client to “Second” or “Third”.

Every time a client connects to a foreign Zim database, it should explicitly use the command CONNECT passing some parameters to identify which database the client wants to connect to and where this database is located (essentially, which Zim Server is controlling this database).

Once the appropriate Zim Server gets the connection request, it starts a ZIM Database Agent that will “talk” to the client from this point on and will perform all operations needed by the client. There will be exactly one agent per connection established.

At the end of the interaction between the client and the agent, the client can disconnect the conversation by issuing the command DISCONNECT which tells the agent to kill itself and breaks the connection between the client and the agent. At this point, the client can no longer interact with the foreign database unless it connects again.

Concurrent Connections

The connections to “Second” and “Third” databases are concurrent because they are performed at the same time without and intervening disconnection. In cases like this one, there is the need to define an alias for the ZIMServer because Zim needs to know which objects are related to each connection. These aliases are defined in the “zimalias.zim” configuration file as described in the Servers Alias Configuration File.