Discussion :

[r0seBa]

Bonjour,

Je suis entrain de réfléchir à organiser une partie de mon application en plusieurs threads. J'ai par exemple 100 fois le même calcul à réaliser avec des jeux de données différents. Chaque calculs faisant des insertions dans la base de données.

Je voulais diviser ce calcul en plusieurs threads (4 ?) mais chaque thread ayant des insertions à faire sur la base de données je me suis dit que ça pouvait devenir critique (même si chaque calcul ne fait pas d'update ou du moins pas sur les même tuples que les autres calculs).

Que pouvez le dire la dessus ? Est-ce que ça pose problème ? Si oui comment faire ?

Merci d'avance

[Invité]

Que pouvez le dire la dessus ? Est-ce que ça pose problème ?

Si tu es sûr que chaque Thread utilise des données différentes et n'effectue que des insertions en base de données il n'y a pas de mise à jour ni de suppression. Alors cela ne posera pas de problèmes de conflits vu que le risque de ne pas respecter la contrainte de clef primaire, d'écraser une donnée existante, de la supprimer est réduite à zéro.

Si oui comment faire ?

Il y a plusieurs méthodes. Tu peux utiliser un pool de thread (regarde la classe ThreadPool) comme tu peux utiliser un ensemble d'instances de la classe BackgroundWorker (cette classe t'offre en plus des évènements très intéressants par rapport à la classe ThreadPool)

[Pol63]

les bonnes bases de données supportent des milliers de connexions simultanément, et pourquoi pas sur la même table, ca s'occupe de gérer l'intégrité et le verouillage

[Invité]

les bonnes bases de données supportent des milliers de connexions simultanément, et pourquoi pas sur la même table, ca s'occupe de gérer l'intégrité et le verouillage

Tout SGBDR (Système de Gestion de Bases de Données Relationnelles) digne de ce nom doit tenir compte de ce que tu viens de dire : intégrité, gestion des accès concurrentiels etc.

Par contre je ne pense pas que le verrouillage soit d'une importance dans le cas présent. Il s'agit d'insertions de données (pas de modification, ni de suppression) alors out le verrouillage d'une ligne. À moins que tu veuilles parler de verrouillage au niveau de la table (je ne vois trop l'utilité dans le cas d'une insertion surtout que les données sont différentes d'après l'auteur de la discussion ).
Admettons qu'il verrouille toute la table alors je me demande à quoi servirait d'avoir plusieurs Thread en parallèle vu que chaque thread devra attendre que le précédent déverrouille la table donc insère toutes les données qu'il manipule pour que l'autre puisse commencer ses insertions. ça revient tout simplement à faire du séquentiel et ce que l'auteur fait actuellement sans aucun verrouillage.

[Pol63]

c'était une explication générique pour dire qu'il n'y a pas à s'inquiéter du nombre de threads qui travaillent sur une base de données

[antoine.debyser]

Admettons qu'il verrouille toute la table alors je me demande à quoi servirait d'avoir plusieurs Thread en parallèle vu que chaque thread devra attendre que le précédent déverrouille la table donc insère toutes les données qu'il manipule pour que l'autre puisse commencer ses insertions. ça revient tout simplement à faire du séquentiel et ce que l'auteur fait actuellement sans aucun verrouillage

Tous dépend de ce qui est le plus long en terme de temps :
- le temps de calcul
- le temps de verrou de la table.

Si mon temps de calcul est de 2 fois plus long que le temps ou ma table reste verrouillé, alors avec 2 threads j'irai presque fois plus vite pour faire mes 100 calculs.

[notia]

Bonjour,

Je suis entrain de réfléchir à organiser une partie de mon application en plusieurs threads. J'ai par exemple 100 fois le même calcul à réaliser avec des jeux de données différents. Chaque calculs faisant des insertions dans la base de données.

Je voulais diviser ce calcul en plusieurs threads (4 ?) mais chaque thread ayant des insertions à faire sur la base de données je me suis dit que ça pouvait devenir critique (même si chaque calcul ne fait pas d'update ou du moins pas sur les même tuples que les autres calculs).

Que pouvez le dire la dessus ? Est-ce que ça pose problème ? Si oui comment faire ?

Merci d'avance

Dans ton cas, je pense que le goulet viendra surtout de l'algorithme que tu vas utiliser pour répartir tes données sur les différents threads.
Lors d'une insertion en base de données, Oracle par exemple, ne fait un lock que sur la ligne concernée. Ce qui n'impactera pas les autres threads.