Заметки на полях: конкурентный доступ в SQL Server

Полагаю, многие разработчики, потратив кучу времени на изучение и систематизацию определенной области знаний, оставляют заметки со списком полезных источников и своими комментариями. И я не исключение. Бывает так, что поставленная проблема разрешена, и применение накопленных знаний какое-то время не требуется. Поэтому такие заметки сильно помогают при необходимости быстро освежить свои знания, когда различные детали и тонкости реализации уже выветрились из кратковременной памяти. Дабы повысить качество подобных записей - я решил попробовать публиковать их. Теперь просто накидать десяток ссылок в Evernote и забыть про них не получится. Надеюсь, заметки перестанут теряться среди сотен других и забываться, а я не буду лениться их делать.

Тема, с которой я хотел бы начать - это уровни изоляции транзакций, блокировки, и pessimistic/optimistic concurrency в SQL Server (нет, я не DBA и не планирую им быть). Attention! Все ниже перечисленное - относится не к книгам целиком, а только лишь к их соответствующим разделам по конкурентному доступу.

Ицик Бен-Ган. Microsoft SQL Server 2008/2012. Основы T-SQL
Принципиальных различий между книгами этого автора для 2008 и 2012 SQL Server немного. Для книг Ицика Бен-Гана характерен легкий, удобочитаемый стиль изложения. Различия уровней изоляции показаны на простейших примерах, для выполнения которых достаточно SSMS. В то же время, информация в книге дана скудная и неполная - например, не рассмотрен update lock. Пожалуй, с этой книжной серии можно начинать знакомство с concurrency в SQL Server, но для знакомых с темой людей она почти бесполезна.

Душан Петкович. Microsoft SQL Server 2012. Руководство для начинающих
В разы больше информации о блокировках. Примеры далеко не так информативны и понятны, в том числе из-за постоянного использования инструкции WAITFOR. В целом уровень изложения чуть выше.

Kalen Delaney. Microsoft SQL Server 2012 Internals
Если первые 2 книги - руководства для начинающих, то вот этот монументальный труд не стыдно прочитать разработчику любого уровня. Самое подробное и всеобъемлющее руководство из тех, что я видел. Держу оригинал книги под рукой в качестве справочника. Стиль изложения объемный и многословный.
Кому чтение книги по каким-то причинам не подходит, могу посоветовать статью от той же Kalen Delaney, содержание в целом соответствует стилю, выдержанному в книге. Там же я узнал, что у Delaney не так давно вышла отдельная книга, посвященная блокировкам в SQL Server:

При этом книжка бесплатная и доступна для скачивания в электронном виде! Да это просто праздник какой-то! Книга так же информативна, как и ее "старшая сестра", держу экземпляр под рукой.

И конечно, не будем забывать про официальную документацию.
TechNet: Locking and Row Versioning

Еще я планировал добавить ворох ссылок на различные мануалы по concurrency с codeproject, хабра и подобных сайтов. Отказался от этой идеи после очередного прочтения  Microsoft SQL Server 2012 Internals. Еще раз всем рекомендую почитать и напоминаю, что я кое-как сравнил между собой только посвященные конкурентному доступу материалы в этих книгах - в районе 1 главы из каждого источника. Удачи!

AutoMapper: internal properties mapping

Ранние версии AutoMapper умели производить маппинг только публичных свойств классов. Ситуация изменилась в версии 3.3.0 - появилась долгожданная возможность мапить не только public, но и internal свойства путем указания перечисления BindingFlags:

Mapper.Initialize(cfg =>
{
   cfg.BindingFlags = 
      BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance;
});

К несчастью, эта фича вновь стала недоступна в версии 3.3.1. По словам автора - так как возникли проблемы с реализацией под все платформы. Есть вероятность, что BindingFlags вернутся в следующих версиях AutoMapper. Обсуждение на GitHub.

AutoMapper: хитрости

Вольный сокращенный перевод понравившегося поста с CodeProject. Рассматриваемые темы:

1. Projection
2. Configuration Validation
3. Custom Conversion
4. Value Resolvers
5. Null Substitution

В отличие от автора, я бы поставил Configuration Validation на первое место по важности. Проверка соответствия свойств класса-результата и класса-источника гарантирует, что любые опечатки, переименования и просто несоответствия имен не останутся незамеченными. Маппинг становится прозрачным и предсказуемым. Но обо всем по порядку:

О переводах и подсознательном

Для разнообразия (не все же время кодить), я перевел пару интересных статей из своей RSS-ленты. Запостил на Хабр, как обычно:

О собеседованиях (от Эрика Липперта)
Гуру C# и просто увлекательный рассказчик, Эрик Липперт объясняет, как собеседует кандидатов на работу, на что обращает внимание и зачем задает те или иные вопросы.

Неразбериха с названиями должностей
Рассуждения сотрудника Stack Exchange о весьма слабой связи между званием (Junior, Senior, Lead и т.п.) и реальными опытом и способностями программиста. Что меняется в жизни Team Lead с большим опытом, если он устраивается на должность Developer.

Обе статьи затрагивают тему технических собеседований, одна с точки зрения интервьюера, другая - с точки зрения соискателя. Мне казалось, что я выбрал статьи случайно, но теперь думаю, что мое подсознание пытается что-то сказать =) И вправду, в рабочие часы сейчас происходит слишком мало интересного. 95% времени уходит на и так хорошо мне знакомые вещи, при этом нагрузка большая, и ни на что другое времени не остается. А жаль, текущий проект - непаханое поле для оптимизации, рефакторинга и различных архитектурных улучшений.

Преобразования конфигурационных файлов. Новая схема

Трюк из моего старого поста, позволяющий трансформировать Web.config при локальной сборке проекта в зависимости от выбранной конфигурации - активно используется на текущем проекте и уже сэкономил команде многие часы работы. Мы используем 5+ конфигураций (Debug, Test, Release, PreRelease и т.п.) для удобного переключения в 5 точках входа между десятком внешних сервисов, 5-6 версиями одной БД, различными оптимизационными настройками и т.п.

Можно ли эту схему упростить еще больше? В некоторых случаях - да, можно.