Notification de la fin d’une fonction asynchrone
Dans le Kit de développement logiciel (SDK) Windows 8, ODBC a ajouté un mécanisme pour notifier les applications lorsqu’une opération asynchrone se termine, ce que nous allons désigner comme « notification à l’achèvement ». (Voir Exécution asynchrone (méthode de notification) pour plus d’informations.) Cette rubrique traite de certains des problèmes pour les développeurs de pilotes.
Interface entre le Gestionnaire de pilotes et le pilote
Le Gestionnaire de pilotes fournit en interne une fonction de rappel SQLAsyncNotificationCallback. SQLAsyncNotificationCallback ne peut être appelé que par le pilote. Une application ne peut pas l’appeler directement. Le pilote appelle SQLAsyncNotificationCallback chaque fois que de nouvelles données reçues du serveur après le dernier retour SQL_STILL_EXECUTING.
Le Gestionnaire de pilotes fournit un mécanisme de rappel afin qu’un pilote puisse avertir le Gestionnaire de pilotes quand une certaine progression a été effectuée lors de l’exécution d’une opération asynchrone après que la fonction correspondante retourne SQL_STILL_EXECUTING
Le Gestionnaire de pilotes définit l’attribut SQL_ATTR_ASYNC_DBC_NOTIFICATION_CALLBACK sur un handle de connexion de pilote avec un pointeur de fonction non NULL, qui est de type SQL_ASYNC_NOTIFICATION_CALLBACK, pour que le pilote fonctionne en mode de notification pour toutes les opérations asynchrones sur ce handle. De même, le Gestionnaire de pilotes définit l’attribut SQL_ATTR_ASYNC_STMT_NOTIFICATION_CALLBACK sur un handle d’instruction de pilote avec un pointeur de fonction non NULL, qui est également de type SQL_ASYNC_NOTIFICATION_CALLBACK, pour que le pilote fonctionne en mode de notification pour toutes les opérations asynchrones sur ce handle.
Si une opération asynchrone est effectuée sur un handle de pilote, les fonctions de pilote asynchrones doivent fonctionner dans un style non bloquant. Si l’opération ne peut pas se terminer immédiatement, la fonction de pilote doit retourner SQL_STILL_EXECUTING. Cette exigence est vraie pour le mode d’interrogation et le mode de notification.
Si un handle est en mode asynchrone de notification, le pilote doit appeler la fonction de rappel de notification, dont l’adresse correspond à la valeur de l’attribut SQL_ATTR_ASYNC_DBC_NOTIFICATION_CALLBACK ou SQL_ATTR_ASYNC_STMT_NOTIFICATION_CALLBACK, une fois retourné SQL_STILL_EXECUTING. En d’autres termes, un retour SQL_STILL_EXECUTING doit être associé à un appel de la fonction de rappel de notification. Le pilote doit utiliser la valeur actuelle de l’attribut de handle SQL_ATTR_ASYNC_DBC_NOTIFICATION_CONTEXT ou SQL_ATTR_ASYNC_STMT_NOTIFICATION_CONTEXT comme valeur pour le paramètre de fonction de rappel pContext.
Le pilote ne doit pas rappeler dans le thread qui appelle la fonction de pilote ; il n’y a aucune raison de notifier la progression avant le retour de la fonction. Le pilote doit utiliser son propre thread pour rappeler. Le Gestionnaire de pilotes n’utilise pas le thread de rappel du pilote pour exécuter une logique de traitement étendue.
Le Gestionnaire de pilotes appelle à nouveau la fonction d’origine après le rappel du pilote. Le Gestionnaire de pilotes peut utiliser un thread qui n’est ni un thread d’application ni un thread de pilote. Si le pilote utilise des informations associées au thread (par exemple, le jeton de sécurité ou l’identificateur utilisateur), le pilote doit enregistrer les informations requises dans l’appel asynchrone initial et utiliser la valeur enregistrée avant la fin de l’opération asynchrone entière. En règle générale, seul SQLDriver Connecter, SQL Connecter ou SQLBrowse Connecter devez utiliser ce type d’informations.