Не знаю на чем основывается мое убеждение.... но, полагаю, если и можно, то это мало отличается от реализации логики на клиенте. Т.е. когда презентационный слой, реализует функционал бизнесс-логики.

ZZZkoderZZZ вот тебе альтернатива http://Windows API

Это еще почему?  

Transact-SQL не подходит для транзакций?  

Ну теоретически можно, а почему нет? Примерно это может выглядеть так: 

Создаешь объект, который будет контролировать транзакцию. Этот объект содержит: идентификатор пользвателя, идентификатор блокируемого ресурса, время начала операции, максимальную ее продолжительность, время последнего подтверждения продолжения операции и максимальный период с момента последнего подтверждения. Дальше забиваешь объект в кеш сервера, и всякий раз, когда запрашивается ресурс проверяешь, есть ли там такой объект и актуален ли он. На стороне клиента нужно поставить таймер, который с определенным интервалом будет отправлять на сервер аякс-запрос, подтверждающий операцию (в случае закрытия страницы запросы отправляться перестанут и объект можно будет удалить). Дальше, если есть другой запрос, проверяешь в кеше наличие данных о проводимой операции и их актуальности, если данные есть - возвращешь сообщение об отказе в доступе.

Не знаю, будет ли это работать именно в том виде, в котором описано(мое знакомство с вебом не такое близкое как хотелось бы), но приблизительно механизм может быть таким. То есть установить постоянное соединение с сервером не получится, но отправлять периодически сообщения можно. Вон посмотри как вконтактик работает: если собеседник оставил сообщение, то у тебя оно появляется практически сразу, а реализовано так же, то есеть постоянно отправляются запросы на обновление и все.

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

Добавлено через 10 минут и 23 секунды
Хотя, вот как мне кажется, в вебе делать такое - не комильфо. Один юзер что-то захватывает, другие ждут и т.д. Это хорошо работать не может.

Согласен, монопольный доступ не нужен.

Примерно потому же, почему .NET лучше Delphi. Об этом много говорят, но никто не может сказать четко и внятно. 

Основные аргументы, я так понимаю - 
1) абстрагирование от плафтормы БД.
2) возможность организовать распределенное хранение данных
3) возможность использовать гетерогенную систему хранения

И ведь действительно, персистить многие объекты бизнесс-локики в РСУБД не рационально. Иные можно заперсистить и в банальном XMLчике


На TSQL реализовывать бизнесс логику- мазохизм.


Это отлично работает на файлсервере. Что хорошего в том, чтобы дать возможность двум пользователям править одновременно один эксельчик, вордик лежащий на общем ресурсе?
Это отлично работает на клиент-сервере. Что хорошего в том, чтобы позволять двум разным бизнесс-пользователям одновременно править одну накладную?
Почему это плохо для веба?


Воспроизведение механизма поддержания сессии. Закат солнца вручную. 

Это сообщение отредактировал(а) Zloxa - 23.3.2013, 12:05

Не понятно, почему вообще к накладной имеет доступ не ответственный за нее пользователь? Опять же доступ может регулироваться сервером приложений, при чем тут клиент?

Это сообщение отредактировал(а) k0rvin - 23.3.2013, 12:12

Монопольный доступ нужен.
Здесь речь не о монопольном доступе а о реализации пессимистической стратегии блокирования ресурсов.


Я имел не то, что у тебя браузер что то там блокирует. Я имел в виду, что у тебя логика представления данных неотделимо связана с логикой обработки данынх. Я предполагаю что вебформы пошли по тому же пути, что и Oracle Forms, просто на другом технологическом базисе.

Добавлено @ 12:18

Пусть будет один пользователь, но из разных окон. Что это меняет? Зачем ему давать возможность править одну накладную в двух окнах?
Пусть второй будет не пользователь, а какойнить серверный процесс.

Ну и ты действительно прав, в условиях правильной постановки бизнесс процесса, ситуации, когда "Один юзер что-то захватывает, другие ждут и т.д." не будет возникать. Здесь вопрос скорее в том, теряем ли мы результат работы пользователя-отступника потому что сам дурак, или же просто не позволяем ему делать дурачью работу.

Это сообщение отредактировал(а) Zloxa - 23.3.2013, 12:27

Zloxa я так понимаю что на на вебормах пользователь получит данные, работает с ними, а потом их посылает на сервер. Там ресурс может быть замкнут, обработан как один процесс и освобожден.
А не так что пользователь зделает запрос на данные, замкнёт их и... незакрывая броузер пойдет пить чай, водку и вернётся завтра. А сервер должен сам решить за какое время он сбросит замок.  

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

Звучит сложновато, но по-моему это наиболее удобный для пользователя способ работы.

Добавлено через 1 минуту и 41 секунду
В любом случае это забота сервера, а не клиента.

Zloxa это ты о чём, обьясни, я непонимаю.

Аааааа, ну тогда правда наверно 

Мне такой подход, особенно на сервере, не нравится. Документ надо парсить каждый раз и загружать в память полностью и это при каждом запросе, а их может быть довольно много и это может сильно загрузить память сервера. Даже если документы небольшие, еще не факт, что они не вырастут. А база - все-таки содержит бинарные данные и там все как раз-таки оптимизировано для хранения и доступа к данным. Если хмл отправляется юзверю в неизменном виде и обрабатывается на стороне клиента, то да, а так...  
Абстрагироваться от платформы видимо хорошо, только вот тебе самому часто со своей оры слезать приходится? Мне кажется, востребованность этой возможности несколько преувеличена. Да и реализацию логики можно возложить не на субд, а на тот же репозиторий данных, уж если такой подход все-таки используется. Ну, а вообще, если не привязываться к конкретной платформе, то просто лишишься тех преимуществ, которые она дает, а придется пользоваться только наиболее общими приемами и соответственно много ненужного перекочует в код программы.

http://technet.microsoft.com/ru-ru/library/ms131102.aspx
  

Ну вот допустим я загрузил документ для редактирования, пока редактировал, хитрый Злоха взял да и отредактировал раньше. Мне приходит сообщение, что документ изменен и прежде чем продолжать редактировать мне будет предложено ознакомиться с новой версией. Можно даже прислать ее сразу же, все с помощью того же аякса реализуется или в крайнем случае приходит сообщение при попытке отправить свою версию. А если доступ блокируется, то как быть с остальными пользователями, которые тоже хотят редактировать?  Они должны ждать? Очередь формировать или там кто быстрее успеет?

Ну здесь же нужно, чтобы другие пользователи знали, что документ редактируется, соответственно все в общий котел валится  

Ну уж как задача поставлена, так она и решена. Я тебе волшебник что ли?  

На самом деле это игрушка. Если на вебформах лепить что-то небольшое и побыстрому, то это самое оно, а так... Здесь просто попытались реализовать такой же подход, как и в винформах. А для чего-то серьезного лучше ASP.Net MVC ессно. Но если говорить о поставленной задаче и ее решении, то тут я отвечал не опираясь на конкретную технологию, просто хттп длительных соединений не поддерживает и для таких задач нужен костыль.

Ну так всегда можно сообщить ему, что документ редактируется.

Та это веб в принципе так работает, а не только формы.

 

Добавлено через 2 минуты и 12 секунд

А тут простых решений быть и не может.

Я или чего то непонимаю, или всё это легко решается в ASP.NET с помощью сесионстат и апликайшенстат и их событий. Там ктому же есть тьма настроек, включая такую вещь как компресия сохраняемых данных.
Но возможно я непонимаю Злоху... и выдумываю здесь  

Это сообщение отредактировал(а) SKrivosein - 23.3.2013, 16:26

Это называется оптимистическая стратегия блокирования


Это называется потеря работы, произведенной пользователем в течении половины рабочего дня


Это еще пол рабочего дня работы


И опять обломаться, потому что кто-то успел изменить документ раньше


Я отстал от времени, или же второй эксельчик позволит открыть себя второй раз лишь только для чтения, не дав хитрому Злохе сохранить документ, пока его редактирует дядявова?


Пессимистическая стратегия блокирования и есть - простое решение. Куда проще не допускать неоднозначности, чем городить огород в попытке сводить не сводимое.

Я как раз говорил о том, что происходит без блокирования. Но ввобще мы о разных вещах говорим. Ты говоришь о корпоративной сети и серьёзной работе с документами и тут мне вообще непонятно, для чего тут использовать веб и браузер, оно и так понятно, что лучше работать с продвинутым клиентским приложением, да и в сети предприятия можно использовать и другие протоколы, да и в общем-то поверх хттп можно сделать как надо с клиентским софтом. Я же говорил о веб сервере с публичным доступом. А ты собственно утверждаешь, что веб недоразвит из-за того, что на нём не слишком красиво реализуются вещи, для которых он не предназначен. Причём даже для них костыль соорудить можно, ну вот всё равно тебе не ндраиццо. 

Пока не предназначен.
Спрос в корпоративном секторе на решения на этой платформе уже давно сформирован.
Удовлетворить же его пока только через зад удается.