Discussion :

[handsome01]

Salut,

Je cherche a faire un Remove de plusieurs éléments d'un hashtable, et je veux qu'après l'opération remove soit complète d'autres éléments s'ajoutent à la même liste hashtable.

Mon problème c'est le risque engendré par le fait que le traitement peut être interrompu pour une raison valable... Alors je cherche un moyen efficace pour implémenter un traitement par lot sur ma collection hashtable a la manière de
SqlTransaction de ADO.net ou similaire ( l'idée prime) : Je supprime des éléments et je rajoute d'autres puis je valide l'opération ( donc LE TOUT ou RIEN ).
voici une simulation simple de ce que je veux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
Obj(ID, VAL)
 
Try
     Machin.BeginTrans
 
     for each k1 as Obj in PremiereListeObjets
          hashtable.remove(k1.ID)
     Next
 
     for each k2 as Obj  in DeuxiemeListeObjets
          hashtable.add(k2.ID, K2)
     Next
 
     Machin.Commit
 
Catch ex As Exception
     Machin.Rollback
End Try

j'ai pensé d'une manière classique en procédant a une copie de ma hashtable mais je pense que ça sera une bonne solution !

Pouvez vous m'aider a résoudre ce problème SVP ?

Merci.

[Pragmateek]

Si ta seule problématique est d'éviter de te retrouver avec un état incohérent parce que tes transformations auraient pétées en plein milieu alors en effet copier est une bonne idée.
Restera juste les affectations finales qui ne seront pas transactionnelles mais je dirais que c'est anecdotique puisqu'elles sont sensées réussir tout le temps (sauf si propriété dont le setter est "riche").

En revanche si tu es dans un contexte multi-threadé alors il faut en plus que tu ajoutes un lock parce que les affectations peuvent être effectuées en 2 temps.

[handsome01]

Si ta seule problématique est d'éviter de te retrouver avec un état incohérent parce que tes transformations auraient pétées en plein milieu alors en effet copier est une bonne idée.
Restera juste les affectations finales qui ne seront pas transactionnelles mais je dirais que c'est anecdotique puisqu'elles sont sensées réussir tout le temps (sauf si propriété dont le setter est "riche").

En revanche si tu es dans un contexte multi-threadé alors il faut en plus que tu ajoutes un lock parce que les affectations peuvent être effectuées en 2 temps.

Merci de m'avoir répondu,

En effet, j'essaie d'éviter le multi-thriding...
A part de recopier l'information, n'existe t-il pas un moyen pour gérer le traitement par lot dans mon cas ?

Merci.

[Pragmateek]

Le bon choix dépend de ta situation:
- priorité à la vitesse => tu ne veux pas bloquer les threads trop longtemps => pas de "macro-lock" autour de l'opération => copie et "micro-lock" pour les affectations
- priorité à la conso mémoire => la copie n'est pas envisageable => "macro-lock" avec "blocage" éventuel d'autres threads
Mais si la copie prend plus de temps que l'opération alors autant tout locker directement.

Sachant que si tu veux du transactionnel pur et pas seulement de la thread-safety tu devras de toute façon copier pour éventuellement annuler.

[handsome01]

Le bon choix dépend de ta situation:
- priorité à la vitesse => tu ne veux pas bloquer les threads trop longtemps => pas de "macro-lock" autour de l'opération => copie et "micro-lock" pour les affectations
- priorité à la conso mémoire => la copie n'est pas envisageable => "macro-lock" avec "blocage" éventuel d'autres threads
Mais si la copie prend plus de temps que l'opération alors autant tout locker directement.

Sachant que si tu veux du transactionnel pur et pas seulement de la thread-safety tu devras de toute façon copier pour éventuellement annuler.

Merci, pour vos conseils précieux... je vais appliquer une de vos méthodes

Si je trouve une autre méthode je la communiquerai.

Merci.

[handsome01]

En fait, dans tous les cas j'aurai le risque de perdre la fiabilité du code quand l'application plante !

la solution de copier les données temporairement subira le même sort lorsque l'application plante ! donc je vois pas l'intérêt de le faire !!

Mon problème n'est pas encore résolu : Comment dois je me procéder afin de traiter deux opérations à la fois si une échoue, l'autre s'annule ou s'applique pas ! ?

Merci

[Pragmateek]

Non justement en copiant les données tu évites les états intermédiaires incohérents :
- soit l'opération est menée à terme et tu as ton nouvel état
- soit ça plante en plein milieu et tu gardes ton ancien état

[handsome01]

Non justement en copiant les données tu évites les états intermédiaires incohérents :
- soit l'opération est menée à terme et tu as ton nouvel état
- soit ça plante en plein milieu et tu gardes ton ancien état

Merci de m'avoir repondu,
je vous comprends, ce que je veux eviter c'est quand l'appli sera entrain de copier les données de l'ancien etat vers son nouvel etat; cela peut causer que certains données seront perdus !

Au lieu de copier les données dans une liste puis recopier vers la BD par exemple il serait judicieux de trouver une solution a la maniere des transactions d'ADO.NET

Existe t-il un moyen pour cela ?

Merci.

[youtpout978]

Bonjour,
je ne suis pas sur que ça peut s'appliquer à votre cas: http://msdn.microsoft.com/en-us/libr...ansaction.aspx

[handsome01]

Bonjour,
je ne suis pas sur que ça peut s'appliquer à votre cas: http://msdn.microsoft.com/en-us/libr...ansaction.aspx

Merci,

J vais essayer d'avoir une idée dessous, et je mettrai si ça va marcher.

Una grand merci.