Безотносительно полезности отключения в целом.
Для «Pro» версии ключа в реестре нет, но можно запустить gpedit.msc…
В Administrative Templates / Windows Components / Microsoft Edge запретить:
Если в следующий раз в TransactionScope будет не создаваться новое соединение, а будет браться из пула вот это первое, то мы получим соединение с уровнем изоляции, отличающимся от желаемого. В этом и состоит проблема.
Проблема точно была в том, что если есть код работающий с БД вне TransactionScope, то ему может приехать из пула уровень Serializable, хотя разработчик рассчитывал на Read Committed. TransactionScope устанавливает по умолчанию Serializable принудительно, с ним вряд ли будут проблемы.
И основная-то проблема в том, что из тех разработчиков, которых я знаю (а, скорее всего и тех, кого не знаю), большинство использует дефолтные настройки — а это, при использовании TransactionScope, уже лотерея.
Однако суть распределенной транзакции заключается как раз в том, что изменения всех участвующих в транзакции управляющих ресурсов либо фиксируются все вместе, либо откатываются.
Не раскрыта тема временных проблем с сетью или падений серверов во время второй фазы. Когда первая половина участников успела закомиттиться, а вторая — нет.
Отличная статья, если хочется получить много теоретических знаний по теме.
Дополню своей практикой:
1) Хорошо, что в статье есть ссылка на другую, про подводные камни. Но ещё лучше было бы и здесь подчеркнуть, что по умолчанию TransactionScope использует Serializable. Интересно, многие ли про это знают? Была бы моя статья — запилил бы опрос :)
Возможно, вам будут говорить, что это неважно и Serializable — отличный выбор. Что же, у меня другое мнение, но кто я такой, чтобы его навязывать? :)
2) Если вдруг у вас в .NET приложении для MS SQL использовались разные уровни изоляции (например, вы в Transact-SQL написали SET TRANSACTION ISOLATION LEVEL SNAPSHOT) и используется connection pool (а он используется по умолчанию) вас ждёт сюрприз (хм, «сюр приз» — раньше не задумывался).
Дело в том, что MS SQL (не буду ничего утверждать про другие СУБД) молча вернёт connection в пул с текущим уровнем изоляции. Подробнее об этом.
Сознательно не привожу более простой пример, когда есть код внутри TransactionScope и вне его (по умолчанию он будет Read Comitted) — хочу спать и не хочу проверять, будут ли на свежем .NET с этим проблемы :)
3) Вот это утверждение расслабляет читателей:
Использование транзакций — дело не сложное, и заключается оно в обертывании кода в блок using с определенными характеристиками. Однако включаемые таким образом в транзакцию управляющие ресурсами должны поддерживать требуемую функциональность со своей стороны.
По факту, даже если забыть про предыдущие два пункта, получаем другую потенциальную проблему. Вот вызвали вы несколько разных методов, который в одном потоке работают с одной и той же БД, но используют чуть разные строки соединения. Здравствуй, распределённая транзакция. Disclaimer: фиг знает, может уже изменили поведение.
4) MS DTC лучше вообще не использовать, если есть такая возможность. Но это совсем другая история…
Резюме: TransactionScope — основательно дырявая абстракция. Так что пользоваться им можно, но отлично понимая последствия.
Ну и ошибки с осадками и облачностью (причём дневные ошибки важнее ночных).
Согласен с тем, что это интереснее. Ошибка для температуры в пару градусов лично для меня не критична (если не около нуля).
Но вот ошибки с осадками у Яндекса — это жесть. Причём не то, что прогноз, часто даже по факту — дождь, когда его нет и наоборот. Корректнее было бы писать «В ближайшие два часа осадков вроде не ожидается».
Ну серьёзно, думал дам шанс. Чуть больше месяца смотрел и на windy.com и на Яндексе. Из того, что пригодилось — пару раз скидывал особенно яркие ляпы с дождями в чатик :)
It is not uncommon to have teams paying 75% “interest” on a combination of unplanned work and task switching.
С точки зрения моего (далеко не отличного) знания английского и здравого смысла (с ним намного лучше): Не редкость, когда команды тратят 75% (времени или усилий) на незапланированную работу и переключение между задачами.
Плохо, что многие сейчас слишком упоролись на почве принципа «Ограниченный выбор».
Апофеоз этого, для меня — ввод логина на одной «странице», а пароля — на другой (пример — Skype, Тиньков).
Относительно приведённых примеров. Может я чего-то не понимаю…
В двух примерах увидел развёрнутый на 90 градусов текст. Это «простота и ясность»?
Кому это может быть удобно? Пока придумал только вариант с 90 и 270 градусами с разных сторон, чтобы шею размять :)
Я обычно полагаю, что разработчики пишут скрипты не с широко закрытыми глазами, поэтому сначала должен быть запущен скрипт на создание, на alter — когда-нибудь потом.
Соответственно, в создающем скрипте проверка на существование может быть, но только для того, чтобы он был пере-запускаемым (это удобно при активной разработке). Точно по тем же причинам, в скрипте с alter существование таблицы не стоит проверять, а вот добавляемых столбцов — может быть полезно. Естественно, в создающем скрипте раздаются права, если это требуется.
Если кто-то запустит скрипт на alter до создающего скрипта — желательно чтобы он упал, потому что, как следствие, стоит исправить что-то в процессе разработки или мыслительных процессах конкретного разработчика :)
P.S. SQL Ninja, в контексте статьи — это кто? Они под покровом ночи делают незаметные для других изменения в БД? :)
Когда читаю очередную статью про полезные советы Мартина (или советы по мотивам его книг), каждый раз хочется прокричать — «Только не забывайте включать критическое мышление!». Сегодня видимо критическая масса накопилась :)
Стоит ли совет про скромность и непогрешимость применять к самому Мартину — решайте сами. Давайте парочку других моментов разберём.
«Зона потока — зло». То есть, предлагается делать себя менее счастливым (подробности есть в книге Поток, и да, расшифровка термина у авторов может чуть отличаться, но база общая). Нет, спасибо. Не знаю как у всех, лично мной в состоянии потока реализовано много красивых идей. То, что потом ревью кода стоит сделать — это не вопрос :)
«Понимают интересы работодателя и заказчика.» vs. «Говорите «Нет»».
Оба пункта горячо поддерживаю. Но предлагаемые варианты как говорить «нет» не показывают понимания интересов.
— Это невозможно, на разработку и отладку поиска нужно две недели.
— Нам нужно показать клиенту в пятницу. Давай постараемся.
В этом разговоре накосячили оба участника (можно спорить кто больше). Если ко мне, как к разработчику, придут с задачей и сроками, которые плохо сосуществуют в одной вселенной, я буду разбираться, как можно что-то в них скорректировать. Если я как менеджер приду к разработчику с такой задачей, я объясню цели показа в пятницу — может, в итоге, нужно показать только визуальную часть или вполне подойдёт реализация только типичного сценария.
Вообще говоря, я не люблю слово «невозможно», особенно, когда его говорят сразу после того, как услышали название задачи. Даже для NP-полных задач :) Ведь если разобраться в том, что действительно необходимо сделать, может оказаться, что алгоритм всегда будет работать на малом объёме данных или вполне устраивает приблизительное решение.
P.S. Про «Код должен быть покрыт тестами на 100%» не буду особо комментировать. Надеюсь, все понимают, что 100% покрытие не гарантирует корректность кода.
Я же не говорю, что половину статьи надо альтернативному подходу посвятить. Просто бывает, что придумывают себе не очень важную цель и потом убивают на её достижение кучу ресурсов.
Disclaimer: когда реально без подгрузки шрифта никак, тут спорить не буду.
Вот, кстати, хорошая статья, где по полочкам разобраны разные подходы: A Comprehensive Guide to Font Loading Strategies.
И речь немного не о том, чтобы на шрифты подзабить, а о том, что периодически полезно заменять ход мыслей «надо показать какие мы особенные и какой у нас хороший вкус», на «вкусы у всех разные и давайте ещё подумаем, как будет удобнее пользователю».
Ещё немного подождать и появятся заголовки «Мужчина взломал Ростелеком, сканируя эти 14 портов...» :)
P.S. После прочтения заголовка вспомнилась тема с «In Soviet Russia» — у нас интернет-провайдер ломает абонентов…
Для «Pro» версии ключа в реестре нет, но можно запустить gpedit.msc…
В Administrative Templates / Windows Components / Microsoft Edge запретить:
youtu.be/K9jCdhKWxrw?t=68
Шикарный момент — «здесь фрагмент кода, явно сырой» и TODOшка на фоне месива из символов — реалистично, да :)
Проблема точно была в том, что если есть код работающий с БД вне TransactionScope, то ему может приехать из пула уровень Serializable, хотя разработчик рассчитывал на Read Committed. TransactionScope устанавливает по умолчанию Serializable принудительно, с ним вряд ли будут проблемы.
И основная-то проблема в том, что из тех разработчиков, которых я знаю (а, скорее всего и тех, кого не знаю), большинство использует дефолтные настройки — а это, при использовании TransactionScope, уже лотерея.
Не раскрыта тема временных проблем с сетью или падений серверов во время второй фазы. Когда первая половина участников успела закомиттиться, а вторая — нет.
Дополню своей практикой:
1) Хорошо, что в статье есть ссылка на другую, про подводные камни. Но ещё лучше было бы и здесь подчеркнуть, что по умолчанию TransactionScope использует Serializable. Интересно, многие ли про это знают? Была бы моя статья — запилил бы опрос :)
Возможно, вам будут говорить, что это неважно и Serializable — отличный выбор. Что же, у меня другое мнение, но кто я такой, чтобы его навязывать? :)
2) Если вдруг у вас в .NET приложении для MS SQL использовались разные уровни изоляции (например, вы в Transact-SQL написали SET TRANSACTION ISOLATION LEVEL SNAPSHOT) и используется connection pool (а он используется по умолчанию) вас ждёт сюрприз (хм, «сюр приз» — раньше не задумывался).
Дело в том, что MS SQL (не буду ничего утверждать про другие СУБД) молча вернёт connection в пул с текущим уровнем изоляции. Подробнее об этом.
Сознательно не привожу более простой пример, когда есть код внутри TransactionScope и вне его (по умолчанию он будет Read Comitted) — хочу спать и не хочу проверять, будут ли на свежем .NET с этим проблемы :)
3) Вот это утверждение расслабляет читателей:
По факту, даже если забыть про предыдущие два пункта, получаем другую потенциальную проблему. Вот вызвали вы несколько разных методов, который в одном потоке работают с одной и той же БД, но используют чуть разные строки соединения. Здравствуй, распределённая транзакция. Disclaimer: фиг знает, может уже изменили поведение.
4) MS DTC лучше вообще не использовать, если есть такая возможность. Но это совсем другая история…
Резюме: TransactionScope — основательно дырявая абстракция. Так что пользоваться им можно, но отлично понимая последствия.
Согласен с тем, что это интереснее. Ошибка для температуры в пару градусов лично для меня не критична (если не около нуля).
Но вот ошибки с осадками у Яндекса — это жесть. Причём не то, что прогноз, часто даже по факту — дождь, когда его нет и наоборот. Корректнее было бы писать «В ближайшие два часа осадков вроде не ожидается».
Ну серьёзно, думал дам шанс. Чуть больше месяца смотрел и на windy.com и на Яндексе. Из того, что пригодилось — пару раз скидывал особенно яркие ляпы с дождями в чатик :)
Да, эти TDDшники такие зайки… :)
С точки зрения моего (далеко не отличного) знания английского и здравого смысла (с ним намного лучше):
Не редкость, когда команды тратят 75% (времени или усилий) на незапланированную работу и переключение между задачами.
Откуда такая информация? Даже для старых дисков говорили про 2N, где N — количество шпинделей.
Если интересно ознакомиться с темой глубже — вот неплохая статья (правда, трёхлетней давности): Управление глубиной очереди дисков для достижения лучшей производительности
Апофеоз этого, для меня — ввод логина на одной «странице», а пароля — на другой (пример — Skype, Тиньков).
Относительно приведённых примеров. Может я чего-то не понимаю…
В двух примерах увидел развёрнутый на 90 градусов текст. Это «простота и ясность»?
Кому это может быть удобно? Пока придумал только вариант с 90 и 270 градусами с разных сторон, чтобы шею размять :)
Соответственно, в создающем скрипте проверка на существование может быть, но только для того, чтобы он был пере-запускаемым (это удобно при активной разработке). Точно по тем же причинам, в скрипте с alter существование таблицы не стоит проверять, а вот добавляемых столбцов — может быть полезно. Естественно, в создающем скрипте раздаются права, если это требуется.
Если кто-то запустит скрипт на alter до создающего скрипта — желательно чтобы он упал, потому что, как следствие, стоит исправить что-то в процессе разработки или мыслительных процессах конкретного разработчика :)
P.S. SQL Ninja, в контексте статьи — это кто? Они под покровом ночи делают незаметные для других изменения в БД? :)
Стоит ли совет про скромность и непогрешимость применять к самому Мартину — решайте сами. Давайте парочку других моментов разберём.
«Зона потока — зло». То есть, предлагается делать себя менее счастливым (подробности есть в книге Поток, и да, расшифровка термина у авторов может чуть отличаться, но база общая). Нет, спасибо. Не знаю как у всех, лично мной в состоянии потока реализовано много красивых идей. То, что потом ревью кода стоит сделать — это не вопрос :)
«Понимают интересы работодателя и заказчика.» vs. «Говорите «Нет»».
Оба пункта горячо поддерживаю. Но предлагаемые варианты как говорить «нет» не показывают понимания интересов.
В этом разговоре накосячили оба участника (можно спорить кто больше). Если ко мне, как к разработчику, придут с задачей и сроками, которые плохо сосуществуют в одной вселенной, я буду разбираться, как можно что-то в них скорректировать. Если я как менеджер приду к разработчику с такой задачей, я объясню цели показа в пятницу — может, в итоге, нужно показать только визуальную часть или вполне подойдёт реализация только типичного сценария.
Вообще говоря, я не люблю слово «невозможно», особенно, когда его говорят сразу после того, как услышали название задачи. Даже для NP-полных задач :) Ведь если разобраться в том, что действительно необходимо сделать, может оказаться, что алгоритм всегда будет работать на малом объёме данных или вполне устраивает приблизительное решение.
P.S. Про «Код должен быть покрыт тестами на 100%» не буду особо комментировать. Надеюсь, все понимают, что 100% покрытие не гарантирует корректность кода.
P.S. У меня не самый быстрый интернет — 20Мбит/c где-то.
Disclaimer: когда реально без подгрузки шрифта никак, тут спорить не буду.
Вот, кстати, хорошая статья, где по полочкам разобраны разные подходы: A Comprehensive Guide to Font Loading Strategies.
И речь немного не о том, чтобы на шрифты подзабить, а о том, что периодически полезно заменять ход мыслей «надо показать какие мы особенные и какой у нас хороший вкус», на «вкусы у всех разные и давайте ещё подумаем, как будет удобнее пользователю».
P.S. И «я тут подумал» имеет смысл заменить на "дизайнеры Medium подумали".
На комментарий потратил больше… но вдруг учтут.