602SQL Documentation Index  

Client - Server Synchronization

Usually the client sends requests to the server and receives results or error reports from the server. The client - server synchronization tools can extend this model. A client can be informed about events that occur on a server as a result of different client actions, such as data changes in a table or a procedure call.

Synchronization Principle

A single event occurrence therefore affects all clients that have this event registered.

Synchronization and Threads

When a client waits for an event, the waiting thread is blocked. If the client wants to make another actions when waiting, he has to run multiple threads. If the client wants to communicate with the server while waiting (e.g. make some database operations or stop the waiting state), the other thread has to connect to the server as well.

Connection to a server with different thread from the same process doesn't consume further licenses.

Event Labeling

Events are labeled by its name with maximum length of 31 characters. Registered events are also marked by an event handler number on the client side.

The name of an event is specified when the event is registered and when invoking the event. The event namespace is common for all clients. It's therefore recommended to use specific event names for each application (e.g. by using the application name as a prefix) if you don't want different application events on the same server to interact.

The event handler is assigned to a client when registering the event. The handler is returned after successful wait for the event. The handler is also used when unregistering the event.

Different clients have different handlers for events of the same name. If a client registers the same event repeatedly, it's assigned different handler.

Events and Transactions

If a client invokes an event, the event occurs after finishing the transaction. If the transaction is rolled back (explicitly or implicitly due to some error), then the event doesn't occur - invoking such an event will have no effect.

Event Parameters

You can set parameters as string characters when invoking an event. A client waiting for an event then receives these parameters.

You can set the required values of parameters when registering an event. Occurrences of an event that don't match this requirements are ignored.

There can be two types of parameter value requirements:

Parameter values comparison is not case-sensitive.

A client can register the same event multiple times with different (or even the same) parameter requirements. If an event with matching parameters occurs, each registration of this event will result in a successful wait stop.

Global and Local Events

In some cases, it is necessary to recognize an event occurrence in one application by a client working in another application. In another cases, such behavior is unwanted, e.g. when multiple instances of the same application are running independently on one server.

That is why a difference to global and local events was introduced. Local event occurrence is recognized only by a client that has set the same schema during the event commit as the client that has caused the event. Global event occurrence can be recognized by all clients that have registered it.

Local event name starts with @ character, global event name starts with a character different from @.

Multiple Events Occurrences

A wait for an event returns also the number of occurrences of that event. The wait comes to a stop on the first occurrence, however the number of occurrences (more than one) may be returned in these cases:

If an event occurs repeatedly with different parameter values, then these occurrences don't sum together. The individual parameter values can be obtained by the client by repeated calls of wait for this event.

If a client has an event registered, it is required to wait for this event with such parameter requirements, so it can be notified of this event. Otherwise event occurrences information would accumulate on the server.

Functions for Handling Events

These functions are available in the client interface: cd_Register_event, cd_Unregister_event, cd_Wait_for_event, cd_Cancel_event_wait.

The Invoke_event function is available on the server as a part of the SQL language.

Also there exists an encapsulating component TSQL602EventAction in the CDK package.