pamir Stub pamir StubКакой смысл от транзакций если они одновременно редактируют одни те же данные. Возникнут колизии и много чего не хорошего.Вот для разруливания коллизий и существуют блокировки. Которые бывают пессимистические и оптимистические. И ими рулит обычно программист. Потому как редко бывает, чтобы правили одни и те же данные. Во всяком случае гораздо реже, чем когда множество параллельных транзакций правят разные данные. Что будет, если пустить их по очереди?
Все это применительно к версионникам. У блокировочников (MSSQL) все как-то иначе, но их я не знаю.

http://www.hibernate.org/hib_docs/reference/en/html/transactions.html (Pessimistic Locking)
Сдесь кажысь тоже кое что есть.Судя по названию сайта (по ссылке не ходил) там будет описание уже в терминах хибернейта. Я же говорил о "чистой" базе. А всякие обертки нужно уже смотреть, как они реализованы.
На самом деле не важно на каком уровне реализованы транзакции и блокировки (правда в данном случаев они естественно должны быть в БД). Смысл понятий "оптимистическая" и "пессимистическая блокировка" от этого не меняется.
Любая система расчитанная на сколько-нибудь серьезную нагрузку при параллельной работе и с серьезными требованиями по масштабированию должна по максимуму использовать оптимистическое блокирование. Особенно в долгих транзакциях. Пессимистические блокировки должны использоваться только тогда, когда это реально обосновано.

Timm Blazkowicz TiGНа самом деле не важно на каком уровне реализованы транзакции и блокировки (правда в данном случаев они естественно должны быть в БД). Смысл понятий "оптимистическая" и "пессимистическая блокировка" от этого не меняется.
Любая система расчитанная на сколько-нибудь серьезную нагрузку при параллельной работе и с серьезными требованиями по масштабированию должна по максимуму использовать оптимистическое блокирование. Особенно в долгих транзакциях. Пессимистические блокировки должны использоваться только тогда, когда это реально обосновано.
Все верно, но стоит так же отметить что вынесение блокировок с уровня базы на уровень приолжения, довольно позитивно влияет на приложение в целом .
Тебе не повезло с СУБД

Любое изменение БД влечет за собой некоторое блокирование на каком-то уровне. Когда сюда добавляется попытка организации блокировок на стороне апликейшна (опять же стоит вспоминить о кластере) возникает масса забавных ситуаций.
Распределенный дедлок - что может быть лучше Кто его будет ресолвить?
[нормальная ;)] СУБД сделает фсе сама.
угу, причем блокировки в БД при изменении данных никуда ведь не денутся. одна сессия держит другую на уровне БД, а та первую - на стороне приложения вот уж точно никакой deadlock detection ни в БД ни в приложении не поможет

Blazkowicz TimmИ чтобы не обсуждать "сферического коня в вакууме", приведи плиз пример "вынесение блокировок с уровня базы на уровень приолжения". Хочу видеть улучшение "производительности в целом" :)
Банально, версии хранить в кэше чтобы попытку записать можно было отшить ещё до обращения в базу. На счет пессимистичного лока пока в голову ничего не приходит. Хотя там тоже рапределенные варианты есть, надо подумать над примером.

Timm" потом все равно перфоманс тюнить" - это хреновая метода. No comments.
Тюнить сразу это не менее хреновая метода, которая называется "превентивная оптимизация". Никто не спорит что блокировки надо делать обдуманно. Но только всегда их делать только в базе мне не кажется разумным.
Timm кстати говорил не про "тюнить сразу", а про то что думать надо обо всех критичных вещах (к которым относится и методика обеспечения многопользовательского доступа и производительность и много других вещей) еще на этапе дизайна. Правильный дизайн зачастую как раз избавляет от необходимости долгой и упорной настройки производительности в дальнейшем, а когда не избавляет, то по крайней мере упрощает её.
А вынос транзакционности полностью на уровень приложения имеет такой большой недостаток, как ограничение возможности работы с данными приложения только через само приложение. А это действительно большое ограничение.
По поводу предлагаемого варианта с кэшем. В OLTP-системе затраты на поддержание данных в кэше в актуальном состоянии могут заметно снизить его полезность. В общем не будем забывать что кэширование наиболее эффективно для активно читаемых данных при сравнительно меньшей (относительно чтений) доле модификаций.

Чендлердавайте оставим в покое OLTP И кеширование на уровне приложения, пусть кеширует субд. Если имеется много приложений причём некоторые на Java(Swing,WEB), C#(GUI), Delphi(GUI) локи нужно делать в бд, на уровне строк. Самый прикол в том что структура табличек может меняться и приходится много переписывать. Так и не нашёл ничего подходящего, чую что придётся писать свой фрейм ворк. Осталось рассмотреть NetBeans, Spring.
Если меняется структура таблиц, то наверное меняется и бизнес-логика работы с этими данными ? В этом случае по любому надо будет что-то изменять/дописывать, разве нет ? Так ли уж надо сразу кидаться "писать свой фреймворк", может попробовать воспользоваться чужими наработками ? Самый быстрый способ сделать что-то - взять уже готовое ;-)
Иногда кстати бывает полезно часть бизнес-логики вынести на сервер БД - когда она используется в нескольких приложениях или подсистемах неоднородного приложения. Бывает очень удобно, часто позволяет повысить производительность. Но, по своему опыту могу смело это утверждать, до определенного предела сложности. PL/SQL очень удобен, полезен и сильно упрощает жизнь при разработке под Oracle, но тем не менее (а) остается процедурным языком (б) нет для него такого огромного количества сторонних разработок на все случаи жизни, которыми можно было бы воспользоваться (в 95% случаев используются свои наработки + стандартные оракловые возможности, которых конечно достаточно чтобы можно было сделать всё что угодно, но ... вы пробовали писать на джаве использую только jdk ? его ведь тоже в принципе вполне достаточно). И я это очень хорошо прочуствовал после двух лет непрерывной разработки сложной, гибко кастомизируемой системы с нуля на чистом PL/SQL. Все успешно завершилось, но "осадочек то остался" ;-)
PS Надеюсь никто не воспримет это как призыв не использовать хранимые процедуры ;) Как раз наоборот - применять для каждого случая тот инструмент, который к этому наиболее приспособлен.
PPS Несколько раз сталкивался с обратной ситуацией - народ реализовывал сам функциональность БД. А БД использовал только как складбище данных. Тоже абсолютно ничего хорошего.
Хм. Куда то я в сторону ушел. Сорри, наболело :))