Discussion :

[Bluedeep]

En tout cas la transaction verrouille la table

Ce n'est pas pour cela qu'il est légitime de faire faire par le programme client ce que habituellement on délègue au SGBD.

[Xploit]

L'autoincrément, si je ne me trompe pas, est utilisé pour auto incrémenter un champ de la table lorsque l'on fait un nouvel enregistrement.

OR dans mon cas il s'agit de faire une mise à jour d'un champ d'un enregistrement existant...

Ceci me parait être un point important qui, s'il est affirmé, m'empeche d'utiliser l'auto increment du SGBD...

Pour en revenir à l'exception OutOfMemory ... j'ai fait tourner l'appli et il me semble qu'il reste de la mémoire disponible lorsque j'ai l'exception ...

[tomlev]

Pour en revenir à l'exception OutOfMemory ... j'ai fait tourner l'appli et il me semble qu'il reste de la mémoire disponible lorsque j'ai l'exception ...

Le fait que ton système ait encore de la RAM disponible ne veut pas dire grand chose...
http://blogs.msdn.com/b/ericlippert/...al-memory.aspx

[swif79]

Et bien ma petite appli consiste à vérifier l'unicité des serials numbers.
Donc il faut pouvoir comparer le numéro traité avec tous les précédents...donc je dirais qu'i il me faut toutes les infos (tous les numéros de série déjà récupéré dans les fichiers de logs) au même moment en mémoire.

Après je pourrais créer une fusion de tous les fichiers de logs en un seul fichier qui contiendrait tous les numéros puis faire le traitement dessus mais c'est pas du tout satisfaisant.

J'aurai bien une idée qui devrait éviter l'outOfMemory mais non performante et t'obligant à former un fichier XML regroupant tes fichier de log.
Ceci dit l'idée serait dont de former un fichier xml vraiment simpliste du genre

Code :

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

1
2
3
4
 
<racine>
    <_numeroDeSérie>Contenu de value</_numeroDeSérie>
</racine>

Tu stocke tes numéros de série dans une liste et quand tu l'a parcours pour avoir accès à value tu fait une requête Xpath sur le fichier XML

[Bluedeep]

Tu stocke tes numéros de série dans une liste et quand tu l'a parcours pour avoir accès à value tu fait une requête Xpath sur le fichier XML

SAuf que affirmer que cela diminura la consommation mémoire me semble plus qu'hasardeux.
Vu à la base le détestable ratio payload/occupation totale du XML cela me semble une idée même un peu tordue.
Mais en gros tu lui suggères de faire ce que je lui proposais via une DB mais avec beaucoup de problèmes potentiels (que ce soit en temps de réponse et en occupation mémoire).

[swif79]

Tu as raison, je viens de tester alors même si j'évite l'outOfMemory (de vraiment rien des value un peu plus grosse et boom), les temps de réponse sont désastreux, c'est une horreur.
La DB est la seul vrai solution...

[giova_fr]

Je crois vraiment en terme de productivité, et d'efficacité, que tu devrais plutot te pencher sur une solution SQL. ton probleme d'unicité et de concurence d'instance c'est du pur probleme d'administrateur SQL !!!

Pour éviter les problemes de concurrence, on fais de la transaction qui garantira que les deux requettes SELECT INSERT se sont bien déroulées, sinon elle annule tout.

Une fois la transaction mise en place, tu peux nettoyer la base en faisant une requette SQL qui vérifie/corrige l'unicité.

Compte tenu du nombre d'entré, je pense vraiment que ca vaut le coup...

[Xploit]

J'utilise effectivement déjà le concept de transaction dont j'ai donné mon utilisation dans un message plus haut.

Là où cela devient délicat c'est que ma transaction n'est pas simplement un SELECT puis un INSERT (nouvel enregistrement dans la table).

Mais un SELECT FOR UPDATE puis un UPDATE d'un champ d'un enregistrement existant.

à ce compte là je ne peux vérifier l'unicité des numéros de série qu'en récupérant les numéros de série grattés par les clients. Je ne peux rien utiliser au niveau serveur pour démontrer l'unicité. En effet tout repose sur la valeur d'un champ d'un seul enregistrement.

Je ne sais pas si j'arrive à me faire comprendre ...
Enfin bref j'ai bien pris note de vos suggestions...

[giova_fr]

Je ne vois pas quel probleme ca pose, quelques que soit les requettes (insert,update, update sur select, etc...) dans ta transcation, et quelque soit le nombre de ces requettes, si tu annule la transaction, ca annule toutes tes requettes.

Ca reste encore un probleme du coté SQL, donc à réglé dans la bdd. Ca sera plus fiable, plus performant, beaucoup beaucoup plus performant vu le nombre d'entrées dans ta table, et tu n'aura pas à fabriquer quelque chose d'exterieur avec toutes les contraintes que çà sous entend !

Bref tu dois absolument rendre ta BDD ACID compliant (voir les 4 points qui définissent ACID, tu es en plein dedans)

en francais, mois détaillé

La majorité des systèmes de gestion de base de données du marché permettent de réaliser des transactions atomiques, cohérentes, isolées et durables.

[Xploit]

Attention il y a peut-être matière à confusion.

Je veux bien que ce soit un pb coté SQL, mais ma transaction me semble correcte. J'aurais juste voulu le démontrer ...

Quand je parlais de hashtable de + 10 Millions d'entrées, c'est bien la structure de données .Net et non pas une table du serveur SQL.

Mes numéros de séries (pour simplifier la chose) sont générés via un seul enregistrement d'une table SQL.

Structure de la table
_____________________________________
|serviceId | vendorId | numero d'allocation(na) |
_____________________________________|
| 00 | 01 | 0 |
_____________________________________|

tous les clients qui veulent un numero de série viennent lire le champ numéro d'allocation correspondant à leur service/vendor.
Chaque client qui vient lire la valeur l'incrémente pour le suivant. Mais ne crée pas de nouvelle entrée dans la table sql c un update...

Code :

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

1
2
3
4
Start transaction
SELECT na FROM table WHERE ...FOR UPDATE
UPDATE table SET na = na + 1 
Commit

Je sais que cette transaction permet de gérer au mieux les accès concurrents et l'unicité des numéros. Cependant j'aurais voulu le démontrer ...

Bon le sujet à bien dévié du sujet premier du post ...