Dans Delphi, le thread TDataSet est-il sûr?

Question

J'aimerais pouvoir ouvrir un TDataSet de manière asynchrone dans son propre thread afin que le thread VCL principal puisse continuer jusqu'à ce que cela soit terminé, puis que le thread VCL principal soit lu à partir de ce TDataSet. J'ai fait des expériences et je me suis retrouvé dans des situations très étranges. Je me demande donc si quelqu'un l'a déjà fait.

J'ai vu des exemples d'applications dans lesquelles un TDataSet est créé dans un thread séparé, il est ouvert, puis les données sont lues, mais tout cela est fait dans le thread séparé. Je me demande s'il est prudent de lire le TDataSet à partir du thread principal VCL après que l'autre thread a ouvert la source de données.

Je fais de la programmation Win32 dans Delphi 7, en utilisant TmySQLQuery à partir de DAC pour MySQL en tant que descendant de TDataSet.

Answer 1

Si vous souhaitez utiliser l'ensemble de données uniquement dans son propre thread, vous pouvez simplement utiliser synchronize pour communiquer avec le thread principal pour toute mise à jour VCL / UI, comme avec tout autre composant.
Ou mieux, vous pouvez implémenter la communication entre le thread principal et les threads de travail avec votre propre système de messagerie.

Vérifiez la solution de Hallvard pour le threading ici:
http://hallvards.blogspot.com/2008/03 /tdm6- knitting-your-own-threads.html

ou cet autre:
http://dn.codegear.com/article/22411

pour des explications sur la synchronisation et ses inefficiences:
http://www.eonclash.com/Tutorials/Multithreading/MartinHarvey1.1 /Ch3.html

Answer 2

Je l'ai constaté avec d'autres implémentations de TDataSet, notamment dans les composants Asta . Ceux-ci contacteraient le serveur, reviendraient immédiatement, puis déclencheraient un événement une fois les données chargées.

Cependant, je pense que cela dépend beaucoup de la composante. Par exemple, ces mêmes composants Asta ne pourraient pas être ouverts de manière synchrone à partir du thread VCL principal.

En bref, je ne pense pas qu'il s'agisse d'une limitation de TDataSet en soi, mais plutôt d'un élément spécifique à la mise en œuvre, et je n'ai pas accès aux composants que vous avez mentionnés.

Answer 3

Une chose à garder à l’esprit lorsque vous utilisez le même TDataSet entre plusieurs threads est que vous ne pouvez lire l’enregistrement en cours qu’à un moment donné. Donc, si vous lisez l'enregistrement dans un fil, puis que l'autre fil appelle Suivant , vous rencontrez des problèmes.

Answer 4

N'oubliez pas non plus que le thread aura probablement besoin de sa propre connexion à la base de données. Je crois que ce dont nous avons besoin ici est un "holding" multi-thread objet pour charger les données du thread dans (écriture uniquement) qui est alors lu uniquement à partir du thread principal de la VCL. Avant de lire, utilisez une sorte de méthode de synchronisation pour vous assurer de ne pas lire le même moment, ni d'écrire au même moment, ou chargez tout dans un fichier de mémoire et écrivez une méthode de synchronisation pour indiquer à l'application principale où se trouve le fichier. arrêter de lire.

J'ai pris la dernière approche à quelques reprises, en fonction du nombre d'enregistrements attendus (et de la taille du jeu de données). Je l'ai même transféré dans un fichier de disque physique sur le système local. Cela fonctionne assez bien.

Answer 5

J'ai effectué un accès multithread aux données, et ce n'est pas simple:

1) Vous devez créer une session par thread.

2) Tout ce qui est fait sur cette instance de TDataSet doit être fait dans le contexte du thread où elle a été créée. Ce n'est pas facile si vous voulez placer par exemple une grille de base de données dessus.

3) Si vous souhaitez laisser, par exemple, le jeu principal avec vos données, la solution la plus simple consiste à les déplacer dans un conteneur séparé, par exemple. un ensemble de données mémoire.

4) Vous avez besoin d'un mécanisme de signalisation pour notifier le thread principal une fois la récupération des données terminée.

... et la gestion des exceptions n'est pas simple, non plus ...

Mais: une fois que vous aurez réussi, l'application sera vraiment élégante!

Answer 6

La plupart des jeux de documents TD ne sont pas thread-safe. L'un de ceux que je connais sans danger pour les threads est kbmMemtable . Il est également possible de cloner un jeu de données de manière à résoudre le problème du déplacement du pointeur d'enregistrement (comme expliqué par Jim McKeeth). Ils constituent l’un des meilleurs ensembles de données que vous puissiez obtenir (acheté ou gratuit).