Comments 9
Что, реально, ни одного комента?:)
Это все потому, что вы про такой мощный инструмент так просто пишете.
Really. Поботайте Microsoft Distributed Transactions service, разрюхайте распределенные архитектуры и распишите использование transaction scope уже в этом контексте.
Вряд ли интересно юзать System.Transactions в рамках одного процесса (гораздо проще IDbTransaction заюзать). В то же время спросите кого угодно про транзакции в сложных архитектурах, и послушайте ответы ;) Возможно, они сподвигнут вас написать еще одну статью, на этот раз с коментами и всеобщим почитанием;)
Это все потому, что вы про такой мощный инструмент так просто пишете.
Really. Поботайте Microsoft Distributed Transactions service, разрюхайте распределенные архитектуры и распишите использование transaction scope уже в этом контексте.
Вряд ли интересно юзать System.Transactions в рамках одного процесса (гораздо проще IDbTransaction заюзать). В то же время спросите кого угодно про транзакции в сложных архитектурах, и послушайте ответы ;) Возможно, они сподвигнут вас написать еще одну статью, на этот раз с коментами и всеобщим почитанием;)
Вряд ли интересно юзать System.Transactions в рамках одного процесса (гораздо проще IDbTransaction заюзатьВот здесь поподробней, пожалуйста. Разве System.Transactions вообще можно использовать не из одного процесса? TransactionScope имеет смысл использовать из одного процесса по нескольким причинам:
1. Доступ в рамках одной транзакции к нескольким источникам данных
2. В этом пункте не уверен — поправьте, если что. IDbTransaction специфичен по отношению к соединению, а значит я вынужден держать соединение открытым на протяжении всей транзакции. В случае TransactionScope за счет использования распределенной транзакции (которая может использовать несколько соединений) код может выполняться в следующем стиле: открыли соединение — запрос — ответ — закрыли соединение, продолжительные операции, открыли соединение — запрос — ответ — закрыли соединение.
3. TransactionScope более декларативен, и его использование в слое сервисов выглядит более естественным. Ну это уже субъективный плюс :)
Возможно, они сподвигнут вас написать еще одну статью, на этот раз с коментами и всеобщим почитанием;)На самом деле отсутствие комментариев связано лишь с тем, что этот пост не взывает к какой-либо дискуссии. Вот предыдущий мой пост был дискуссионным, а этот — нет.
1) ок
2) профайлер вам в помощь;)
3) хз. имхо хрень
про дискуссию — ну вот написали вы статью, получили свои плюсики. с тем же успехом можно было дать ссылку на мсдн.
про распределенные архитектуры — ботайте MSDTC, MSMQ, книжки по архитектуре.
2) профайлер вам в помощь;)
3) хз. имхо хрень
про дискуссию — ну вот написали вы статью, получили свои плюсики. с тем же успехом можно было дать ссылку на мсдн.
про распределенные архитектуры — ботайте MSDTC, MSMQ, книжки по архитектуре.
хз. имхо хреньВ первый раз вижу программиста, который уместное применение декларативного подхода называет «хренью». Как, например, насчет того, что декларативный подход позволяет в две строчки заставить существующий код поддерживать транзакции?
про дискуссию — ну вот написали вы статью, получили свои плюсики. с тем же успехом можно было дать ссылку на мсдн.Какую ссылку? Если вам показалось, что эта статья — перепечатка MSDN'а, — вы сильно ошибаетесь
про распределенные архитектуры — ботайте MSDTC, MSMQ, книжки по архитектуре.От всей души желаю, чтобы вам всегда отвечали в таком же духе.
В целом, да, Transaction можно передавать через AppDomain, но ни один пункт статьи от этого не теряет своей актуальности.
вместо того, чтобы немного напрячь свой мозг и эрудицию, вы хотите поругаться. я ругаться не хочу и не буду, так как сильно занят.
но ладно, так уж и быть, сейчас я пью кофе и нагуглю все за вас. итак, распределенные архитектуры, краткий ликбез.
если приложение распределенное, это значит, что существуют отдельные процессы, которые в своей работе друг от друга зависят. если процессы разделены, то это скорее всего значит, что общение между ними происходит посредством сообщений. если один из процессов хочет быть транзакционным и случайно не нарушить целостность, то все, что ему нужно — это иметь транзакционный контроль над очередями сообщений. это к вашему пункту 1 замечание, что транзакции не только в данных бывают.
ну и все, куча архитектур подобным образом построена. бери любую, описывай, получай карму и плюсики.
но ладно, так уж и быть, сейчас я пью кофе и нагуглю все за вас. итак, распределенные архитектуры, краткий ликбез.
если приложение распределенное, это значит, что существуют отдельные процессы, которые в своей работе друг от друга зависят. если процессы разделены, то это скорее всего значит, что общение между ними происходит посредством сообщений. если один из процессов хочет быть транзакционным и случайно не нарушить целостность, то все, что ему нужно — это иметь транзакционный контроль над очередями сообщений. это к вашему пункту 1 замечание, что транзакции не только в данных бывают.
ну и все, куча архитектур подобным образом построена. бери любую, описывай, получай карму и плюсики.
Вы явно на другой волне. Статья была о нюансах использования TransactionScope. Ни о распределенных архитектурах, ни о MSMQ, ни о чем другом. Если вы соберетесь использовать TransactionScope из нескольких AppDomain, то увидите все те же описанные в статье нюансы. Если я захочу написать статью о распределенных архитектурах, вы первый об этом узнаете.
в стандарте в качестве дефолтного рекомендуется использоВАть Read Committed
Sign up to leave a comment.
TransactionScope — заманчивый, но коварный