Subject | Re: [Firebird-Architect] Re: Vulcan services engine info. was (engine information (nr. of attachments, databases, db-name-info) |
---|---|
Author | Dimitry Sibiryakov |
Post date | 2006-05-08T16:30:53Z |
On 8 May 2006 at 16:37, Arno Brinkman wrote:
on client side has two connections to different servers in conection
table. When asked for number of opened database it wakls through
connections table and ask every provider to count opened db. Engine
providers will return 1. Remote providers will send request to remote
dispatcher. The procedure will be repeated there and total number of
DB will be returned. At last, the dispatcher will return total number
of opened databases though all levels of dispatchers.
May work...
--
SY, Dimitry Sibiryakov.
>good to me. The services module can call the in the Y-valveNot all known but all loaded. Let's start from example: dispatcher
>(Dispatcher) to ask for engine information and the dispatcher will
>walk through all known providers and his subsystems to ask for
>information. This way the services module is able to handle return the
>needed information.
on client side has two connections to different servers in conection
table. When asked for number of opened database it wakls through
connections table and ask every provider to count opened db. Engine
providers will return 1. Remote providers will send request to remote
dispatcher. The procedure will be repeated there and total number of
DB will be returned. At last, the dispatcher will return total number
of opened databases though all levels of dispatchers.
May work...
>The Y-valve methods inherited also from the sub-system and thoseExactly. Dispatcher also is (some kind of) provider.
>handles (dbHandle, svcHandle, reqHandle, blobHandle, ...) are
>internally mapped to the calling provider handles. For the engine-info
>call we don't have a (engine-) handle and i doubt if we need it.
--
SY, Dimitry Sibiryakov.