Можно ли использовать CER, чтобы гарантировать, что finalize никогда не будет вызван?

У нас есть очень сложная проблема взаимодействия, в которой поток, используемый для инициализации сторонней системы, должен быть тем же потоком, который используется для ее завершения. Невыполнение этого требования приводит к тупиковой ситуации. Мы выполняем взаимодействие из службы WCF, размещенной в IIS. В настоящее время эта очистка сделана в утилизации и обычно работает очень хорошо. К сожалению, при большой нагрузке IIS будет выполнять грубую выгрузку, и мы никогда не сможем вызвать dispose. Мы можем переместить логику выключения в критический финализатор, но это не поможет, поскольку у нас больше нет доступа к инициализирующему потоку! На данный момент нашим единственным выходом, похоже, является уведомление CLR о том, что AppDomain теперь, вероятно, находится в поврежденном состоянии. Однако я не уверен, как это сделать (и если это вообще возможно). Возможно, в этом заключается полезность контрактов на уровне класса, но я признаю, что не совсем понимаю их.

РЕДАКТИРОВАТЬ: В качестве альтернативы это можно рассматривать как проблему сходства потоков в финализаторе. Если у кого-то есть умное решение, я весь внимание :)


multithreading c# iis interop cer
person Jeff    schedule 12.03.2012    source источник
comment
Является ли компонент, с которым вы имеете дело, родным или управляемым?   -  person JaredPar    schedule 13.03.2012
comment
Родной. Это api для системы с собственным управлением памятью и т. д.   -  person Jeff    schedule 13.03.2012

Ответы (1)


arrow_upward
1
arrow_downward

Попробуйте разделить код, который зависит от этой собственной зависимости, на отдельное приложение-службу Windows, если это возможно. Если он не может хорошо работать с WCF/IIS, вам следует избегать конфликтов, а не бороться с ними.

person Lex Li    schedule 13.03.2012
comment
Да, возможно, вы правы. Мы говорили об этом, хотя я пока не хочу сдаваться :) - person Jeff; 13.03.2012
comment
Кроме того, я должен был сказать - я не уверен, что это действительно решает проблему, поскольку выгрузки CLR, вероятно, являются фактом жизни (хотя я уверен, что это менее вероятно в вашем решении). - person Jeff; 13.03.2012
comment
Вы имеете в виду, что вы чувствуете себя плохо из-за выгрузки приложения? Так задумано, так как пул приложений будет периодически перерабатываться (узнайте о настройках), а ASP.NET также перезапускается, stackoverflow.com/questions/829392/ - person Lex Li; 14.03.2012
comment
Я не уверен, что ты имеешь в виду под плохим самочувствием. Когда приложение выгружает мои блоки finally, они не вызываются. Это поведение CLR, а не поведение ASP.NET, хотя, как я уже сказал, оно с большей вероятностью проявится в IIS. - person Jeff; 21.03.2012
comment
Что ж, всем .NET-разработчикам приходится приспосабливаться к тому факту, что вызов финализаторов не гарантируется. Поэтому решить проблему взаимодействия, с которой вы сталкиваетесь только в ASP.NET, непросто. В модели ASP.NET нет возможности контролировать жизненный цикл объектов, поскольку он управляется ASP.NET/IIS. Однако перемещение части в приложение-службу Windows должно дать вам больше контроля над жизненным циклом объекта. - person Lex Li; 26.03.2012
comment
Опять же, я думаю, вы путаете ASP.NET и CLR. ASP.NET не контролирует время жизни объектов (хотя может контролировать время жизни домена приложения), это делает CLR. Идея принудительного выполнения (или критического финализатора) хорошо известна в среде CLR. - person Jeff; 03.04.2012