Discussion :

[siriu]

Bonjour,

Je viens de découvrir qu'on peut utiliser en JAVA des threads donc excusez moi par avance si ma question vous parait simple.

Je voudrai dans une méthode lancer dans un nouveau thread un UPDATE important de base de données ... (ça c'est bon ça fonctionne)

Ma question est comment faire pour ne pas lancer ce nouveau thread s'il y en a déjà un de lancé ? (faire une sorte de singleton)

Merci par avance pour votre aide ?

[joel.drigo]

Salut,

Il y a différents moyens de faire ça avec un thread. Cela dépend un peu de ce que tu cherches à faire :

• mettre en attente l'update, en attendant que le premier soit terminé ;
• ne pas faire cet update, s'il y en a en cours ;
• autres...

Mais ce sera toujours plus ou moins complexe, selon les cas. La solution d'utiliser un ExecutorService, comme un Single Thread Executor, te permettra très facilement, de faire tes updates les uns après les autres.

[star]

Cela n'empêchera pas le même UPDATE d'être exécuté à partir d'une autre machine...
.

[siriu]

Merci pour vos réponses

Pour expliquer un peu plus ce que je cherche à faire

Cette méthode (qui lance ce nouveau thread) est appelée lorsqu'une personne modifie une ligne sur une appli en FLEX...
Elle update par un SQL une ligne dans une table puis lance deux méthodes qui font des cumuls et des calculs pour maintenir la table à jour.

Maintenant modifier une ligne sur l'appli met 2 secondes donc si un utilisateurs modifie 100 lignes, ça me lance 100 fois pour l'instant le même update

Donc j'aimerai trouver une solution pour empêcher qu'un UPDATE se réalise s'il y en a déjà un en attente ...

Et le fait de lancer cet update dans un nouveau THREAD est intéressant car ça me permet de rendre la main a l'appli FLEX avant que ne soit réalisé l'UPDATE.

Si vous avez des pistes je suis preneur

[joel.drigo]

Elle update par un SQL une ligne dans une table puis lance deux méthodes qui font des cumuls et des calculs pour maintenir la table à jour.

Je ne comprends pas : on update un enregistrement, on fait des calculs, puis on update le même enregistrement ? C'est ça ?

Maintenant modifier une ligne sur l'appli met 2 secondes donc si un utilisateurs modifie 100 lignes, ça me lance 100 fois pour l'instant le même update

Les questions a se poser déjà c'est pourquoi :

1. il faut autant de temps pour modifier 100 lignes ?
   C'est le calcul qui prend autant de temps ? Pourquoi doit-on mettre à jour les données avant le calcul ?
2. Pourquoi une mise à jour ferait 100 fois la mise à jour ?
   Normalement, si l'utilisateur modifie une donnée, cela doit faire un seul update. S'il modifie 100 lignes, cela doit faire 100 updates d'enregistrement différents à priori (qui peut correspondre à un seule update dans un cas particulier mais qui pour la plupart du temps correspond bien à 100 updates). A moins qu'il ne s'agisse d'une autre table, dans laquelle on stocke des données résultantes d'un calcul sur ces 100 lignes (comme une ligne de total sur un facture par exemple) ?

[siriu]

Je ne comprends pas : on update un enregistrement, on fait des calculs, puis on update le même enregistrement ? C'est ça ?

En fait l'application FLEX affiche des lignes venant d'une table SQL à un utilisateur.
Celui-ci peut en fonction de ses besoins les modifier.
S'il modifie une ligne, celle ci est UPDATE dans la table SQL par une méthode JAVA.
La ligne modifiée fait partie de différents résultats aggrégée et calculé, donc après update, l'application refait tourner les calculs et les aggrégations.

J
Les questions a se poser déjà c'est pourquoi :

1. il faut autant de temps pour modifier 100 lignes ?
   C'est le calcul qui prend autant de temps ? Pourquoi doit-on mettre à jour les données avant le calcul ?
   

1. Lorsque je parles de 2 secondes, c'est coté application client FLEX, l'utilisateur qui modifie une ligne peut passer que 2 secondes sur la ligne.
   
   Après celle-ci est updatée dans la base de données puis les calculs se font...
   
   

   J

2. Pourquoi une mise à jour ferait 100 fois la mise à jour ?
   Normalement, si l'utilisateur modifie une donnée, cela doit faire un seul update. S'il modifie 100 lignes, cela doit faire 100 updates d'enregistrement différents à priori (qui peut correspondre à un seule update dans un cas particulier mais qui pour la plupart du temps correspond bien à 100 updates). A moins qu'il ne s'agisse d'une autre table, dans laquelle on stocke des données résultantes d'un calcul sur ces 100 lignes (comme une ligne de total sur un facture par exemple) ?

[joel.drigo]

C'est sûr, mais je ne vois pas le rapport. La question; telle qu'elle est posée, est de savoir comment éviter que la tâche faite par le thread puisse être appelée de manière concurrente. En tout cas, c'est comme ça que je l'ai comprise. Je suppose que c'est pour éviter d'utiliser la même connexion pour les 2 updates, au lieu d'utiliser un pool. A ce propos, la méthode par ExecutorService est applicable à n'importe quelle type de tâche.
S'il est question d'éviter de faire 2 updates des mêmes données en même temps, c'est sûr que ce n'est pas comme ça qu'il faut aborder la chose : il y a les transactions pour ça !