Тут, как мне показалось, больше важна не величина задержки, а факт ее наличия. Час или сутки — принципиальной разницы нет. Проще уже сделать одну задачу, а результат посмотреть на следующий день, чем постоянно прыгать между задачами или курить бамбук, дожидаясь результатов.
Да и в реальном использовании наличие этой задержки практически не сказывается, она мешает только при «дебаге».
А они и не запрещали все СПО. Есть запрет только на GPL и похожие вирусные лицензии. Софт с под лицензиями Apache, BSD, MPL, и их аналогами изначально разрешен в маркете. Alizar просто немного преувеличил. Есть официальное пояснение от команды winphone и нет причин им не верить.
Мне здравый смысл подсказывал, что использовать TransactionScope — безопасно. У вас есть 100% уверенность, что в приложении косвенно не используется пул? Где граница использования потоков? TPL можно использовать? PLINQ? Как насчет стандартных Async Pages?
При исключении в таске в TPL — приложение падает при вызове финализатора, что еще интереснее в отладке.
Обычные Win приложения тоже падают при исключении на потоке из пула — но это не повод отказываться от многопоточности или исключений.
>> (Ну и IIS-то все равно не падает)
Я же проверил перед тем, как написать комментарий. И DevServer, и IIS7 под .NET 4 Integrated Mode падают при вписывании строчки в Page_Load на стандартном шаблоне сайта.
Где и кем не рекомендуется? В MSDN? Покажите ссылку, пожалуйста. Вы же не гуглите каждый метод CLR на предмет безопасности под IIS?
Пример валит IIS, в статье по QueueUserWorkItem предупреждения нет — этого достаточно, чтобы кто-то наступил на грабли.
Стандартный TransactionScope использует потоки из пула для реализации таймаутов. Любой зарегистрированный в нем ресурс может кинуть исключение в момент rollback-а, и точно так же утянет за собой w3wp. И, да, я видел такое на своем проекте, на живой системе. TransactionScope тоже не рекомендуется использовать?
Не обманули, скорее — очень раздули проблему. Например, исключение на потоке из пула убивает IIS, точнее, процесс, обслуживающий Application Pool: ThreadPool.QueueUserWorkItem(delegate { throw new Exception(); });
И тут же в логах: Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2…
Но это не настолько серьезный аргумент, чтобы переходить с исключений на коды ошибок.
Идея понятна, но где подтверждение, хоть одной ссылкой?
Да, я настраивал зеркалирование на практике, для большого количества баз одновременно. И точно знаю, что на самом деле все не так, как вы описали. Базы не обращаются друг к другу. Все отзеркалированные базы используют те же 5-6 постоянных соединений.
Аутентификация происходит при установлении соединения, один раз, это явно сказано в msdn.microsoft.com/en-us/library/ms186360.aspx: Connection requests from a partner or witness, if any, must be authenticated.
Соединения устанавливается один раз, при старте первой сессии. Попробуйте настроить зеркала для нескольких баз и сделать выборку из sys.dm_db_mirroring_connections. Соединения постоянные, никуда не пропадают. Из описания dmv тоже достаточно очевидно, что аутентификация — часть connection handshake, а не самого протокола передачи транзакций.
Аутентификация для mirroring endpoint в любом случае будет, но она же на скорость работы установленного соединения не влияет. Может притормаживать шифрование, но оно задается отдельной опцией.
Кстати, срок действия сертификатов по умолчанию — год, что может стать неприятным сюрпризом. И настройка для Windows Authentication немного проще — позволяет первые три пункта сделать через UI.
Необходимость в ручном вызове естественно бывает, иначе возможности его сделать просто не было бы. Но в таких жестких условиях просто вызова GC — мало. Нужно полноценное ужимание приложения — ngen для шаринга native images, MemoryFailPoint-ы, и полное понимание всех деталей работы GC. К сожалению, обычно ручная сброка мусора используется «на всякий случай».
IDisposable.Dispose() не освобождает память, и вообще не имеет отношения к управлению памятью. Он освобождает остальные ресурсы, а память так и остается занятой до сборки мусора.
Я иногда подсказываю планировщику запросов в SQL. FORCESEEK в моем текущем проекте местами очень помогает против дедлоков при read committed snapshot. Это плохо?
Некоторым достаточно статьи. Некоторым — недостаточно Рихтера.
Как ни грустно, но большинство разработчиков — непрофессионалы. Есть много студентов/джуниоров/просто не перечитывающих каждое издание Рихтера/Руссиновича/Робинса заново. Есть даже такие, что по it-тематике читают только хабр. Эта статья будет хотя бы на главной хабра, и в комментариях будет упоминаться Рихтер — уже этим она полезна.
Это аналог вызова EmptyWorkingSet. Он не освобождает память. Просто урезает private working set — значение, которое по умолчанию показывает task manager.
Естественно, последующий своп и тормоза при этом обеспечены. Иметь на среднем десктопе 4Gb памяти, и при этом принудительно заставлять приложение свопить и не выходить за пределы 10 мегабайт — преступление.
Посмотрите статью habrahabr.ru/blogs/windows/107605/ — там в разделе task manager есть даже скрипт для «оптимизации всего подряд», вместе с обоснованием «полезности» такой «оптимизации».
Да и в реальном использовании наличие этой задержки практически не сказывается, она мешает только при «дебаге».
При исключении в таске в TPL — приложение падает при вызове финализатора, что еще интереснее в отладке.
Обычные Win приложения тоже падают при исключении на потоке из пула — но это не повод отказываться от многопоточности или исключений.
>> (Ну и IIS-то все равно не падает)
Я же проверил перед тем, как написать комментарий. И DevServer, и IIS7 под .NET 4 Integrated Mode падают при вписывании строчки в Page_Load на стандартном шаблоне сайта.
Пример валит IIS, в статье по QueueUserWorkItem предупреждения нет — этого достаточно, чтобы кто-то наступил на грабли.
Стандартный TransactionScope использует потоки из пула для реализации таймаутов. Любой зарегистрированный в нем ресурс может кинуть исключение в момент rollback-а, и точно так же утянет за собой w3wp. И, да, я видел такое на своем проекте, на живой системе. TransactionScope тоже не рекомендуется использовать?
ThreadPool.QueueUserWorkItem(delegate { throw new Exception(); });И тут же в логах: Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2…
Но это не настолько серьезный аргумент, чтобы переходить с исключений на коды ошибок.
Да, я настраивал зеркалирование на практике, для большого количества баз одновременно. И точно знаю, что на самом деле все не так, как вы описали. Базы не обращаются друг к другу. Все отзеркалированные базы используют те же 5-6 постоянных соединений.
Аутентификация происходит при установлении соединения, один раз, это явно сказано в msdn.microsoft.com/en-us/library/ms186360.aspx: Connection requests from a partner or witness, if any, must be authenticated.
Соединения устанавливается один раз, при старте первой сессии. Попробуйте настроить зеркала для нескольких баз и сделать выборку из sys.dm_db_mirroring_connections. Соединения постоянные, никуда не пропадают. Из описания dmv тоже достаточно очевидно, что аутентификация — часть connection handshake, а не самого протокола передачи транзакций.
Я иногда подсказываю планировщику запросов в SQL. FORCESEEK в моем текущем проекте местами очень помогает против дедлоков при read committed snapshot. Это плохо?
Да, там надо пару раз по ссылкам пройтись. Но Рихтер с 70-ю страницами и 20+ разделами в главе тоже явно в формат статьи не впишется.
Как ни грустно, но большинство разработчиков — непрофессионалы. Есть много студентов/джуниоров/просто не перечитывающих каждое издание Рихтера/Руссиновича/Робинса заново. Есть даже такие, что по it-тематике читают только хабр. Эта статья будет хотя бы на главной хабра, и в комментариях будет упоминаться Рихтер — уже этим она полезна.
Естественно, последующий своп и тормоза при этом обеспечены. Иметь на среднем десктопе 4Gb памяти, и при этом принудительно заставлять приложение свопить и не выходить за пределы 10 мегабайт — преступление.
Посмотрите статью habrahabr.ru/blogs/windows/107605/ — там в разделе task manager есть даже скрипт для «оптимизации всего подряд», вместе с обоснованием «полезности» такой «оптимизации».