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

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

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

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