dans le finalize il reste possible d'appeler une méthode statiques quelque part qui s'occupera de faire ton traitement, ou au moins de se noter quelque part que ca doit etre fait et de rendre la main au finalize directement
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
J'aime pas trop passer par du statique pour gérer des action sur une classe mais ça marche parfois en effet
Par contre, il ne faut pas oublier que dans ce cas on passe par défaut dans un contexte multithreadé et il ne faut pas oublier d'utiliser des lock() pour éviter les problèmes.
Et si je vire le finalize pour ne laisser alors que le Dispose, celui-ci sera-t'il appellé par le GC ?
nonEnvoyé par Sergejack
il faut l'appeler toi même
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
Ok.
Donc quand un objet est lié à des données en DB qui devraient disparaître à la mort de l'objet, il est impossible par ces principe de garantir que cela sera le cas si par exemple, le CLR est remplacé ou l'application fermée.
Finallement on ne peut rien faire dans ces deux cas où finalize est appellé sur l'ensemble des objets en mémoire (vu que rien n'est alors utilisable pour opérer sur la DB) ?
C'est pour ça que j'ai horreur du GC
Quand on veux programmer une véritable action à la mort d'un objet, on est obligé d'employer des tricks mais le refcount ça marche assez bien.
A mon avis, c'est pas une bonne idée de se baser sur la "mort" d'un objet pour effectuer une action...C'est pour ça que j'ai horreur du GC
Quand on veux programmer une véritable action à la mort d'un objet, on est obligé d'employer des tricks mais le refcount ça marche assez bien.
Dans le cas de Sergejack, je pense que la meilleure solution serait de mettre le code de nettoyage dans le Session_End du Global.asax
C'est sur que c'est normalement une très mauvaise idée mais il y a des fois où l'on ne peut pas vraiment faire autrement ...
J'y ai songé, mais il resterait le problème de l'impossibilité de faire du nettoyage à l'arrêt du site (site stoppé ou dll remplacées).
Et comme je le disais, refcount ou quoi que ce soit, à l'arrêt du site, les jeux sont faits, rien ne va plus.
Mon nettoyage DB, je vais devoir le faire ailleurs en fonction de paramètres décisionnels "est-ce que ceci semble devoir être supprimé ?".
Merci pour les éclaircissements.
Justement, j'en suis pas si sûr... tu as fait des tests ? à mon avis les évènements d'arrêt de l'application sont quand même exécutés avant que l'appli ne soit déchargée et redémarrée. Donc avec un peu de chance, le Session_End aussi...
Bon, ben j'ai rien dit... IIS est moins malin que je pensais
J'ai fait le test, même le Application_End n'est pas exécuté. C'est un peu crade je trouve
Répondre avec citation
Partager