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.Citation:
Envoyé par Xploit
Version imprimable
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.Citation:
Envoyé par Xploit
Ceci me parait être un point important qui, s'il est affirmé, m'empeche d'utiliser l'auto increment du SGBD...Citation:
Envoyé par Xploit
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...Citation:
Envoyé par Xploit
http://blogs.msdn.com/b/ericlippert/...al-memory.aspx
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.Citation:
Envoyé par Xploit
Ceci dit l'idée serait dont de former un fichier xml vraiment simpliste du genre
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 XMLCode:
2
3
4<racine> <_numeroDeSérie>Contenu de value</_numeroDeSérie> </racine>
SAuf que affirmer que cela diminura la consommation mémoire me semble plus qu'hasardeux.Citation:
Envoyé par swif79
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).
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...
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...
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...
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é
Citation:
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.
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...
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 ...Code:
2
3
4
Bon le sujet à bien dévié du sujet premier du post ...