External Components – Database Query Implementation

External Components – Database Query Implementation

Database Application:

The C# program to access databases has been created as pretty much a clone of parts of the display app.  That is, it uses modifications of the display code

A) to read the configuration file and load and run its paired Ada application,

B) use MS_Pipe named pipe threads to communicate with the paired application for each database to be supported,

C) create a specific thread for each supported database to interface with the database,

D) an instance of a queue for each database into which to add received query messages.

As with the display app, the database app periodically wakes up each of the database access threads.  When awoken these threads check their queue to determine if it has any entries received from a user app.  If so, it dequeues the query message and acts on it and then causes the data retrieved from the database to be transmitted to the user application that sent the query.

Further development is needed to add commands such as Open and notifications to the user app such as the database is not connected or has become disconnected.  That is to have the Database Interface component control the opening of the database in a manner similar to the A661 user app controlling the enabling of a layer and being notified when the layer becomes inactive.

Database Interface Component:

The very basics of the Database Interface component of the user application has been created in order to check the ability of the user application's components to publish framework topics that the Database Interface Component (see diagram of the April 29 post "External Components – Database Queries") then consumes.

Generalized features such as those intended for the Schema package of the diagram have yet to be worked upon.  That is, there is nothing as yet to read the schemas for various databases and associate potential queries and database updates with particular interpretation procedures to translate a received topic to a query to be transmitted to a particular database and to translate the response from the database to the response topic to be returned to the requesting component.

Only the minimum has been done to check whether a user component can publish a topic that the DBI1 database interface component subscribes to consume.  This minimum to check that when a topic is received by the database interface component that it can then create and transmit an associated query, get the query response, and then send a topic response back to the requesting user component.

With this sample topic/query treatment the database interface component checks whether its connection to the external database application has been made so that the query can be sent.  If not, it sends a response back to the requesting component that the request wasn't honored.  Otherwise, it creates the query and transmits it to the database app.  When the response is received, it is placed into the received message queue of the database interface component and a wakeup event for the component is sent to the framework.  The database interface component is than run by the framework and it retrieves the query response from the queue and creates the response to return to the requesting component.

Detected Framework Insufficiency:

Before the connection to the external database application occurs the database interface component creates the not handled response and publishes it.  The requesting component then is run by the framework and it gets the response topic.

After the connection to the external database application occurs the database interface component creates and transmits the query.  It then receives the response from the database application via the Receive thread of the instantiation of the generic MS_Pipe package and creates and publishes the response topic. 

The newly detected framework problem is that this response topic is not delivered to the requesting component.

After trying for a while to determine the reason for this, it has occurred to me that it is because the Request/Response message exchange method was implemented with the expectation that the response would be published before the request consumer component returned to the framework after being notified of the request.

The framework then delivers the response and the topics are released.  Since it isn't necessary for the requesting component to subscribe for the response, the framework can ignore the published response rather than attempt to deliver it when the requesting component didn't subscribe for it.  Therefore, the topics are released without regard to whether the response was delivered. 

At least I think that is what is happening.  Therefore, I will change the release to avoid releasing the request if the requesting component subscribed for a response but the response has yet to be published. 

This should be easy enough since I already have code to detect whether the requesting component subscribed for a response.  So all that will be necessary is to do the same check for the release as well as a new check for whether the response has been published.  Where an additional problem may arise is to keep doing attempts to do the release until the response has been published and delivered.

Therefore, these changes will be made to the framework before generalizing the database interface and making the additions to the database application.