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 Несколько раз сталкивался с обратной ситуацией - народ реализовывал сам функциональность БД. А БД использовал только как складбище данных. Тоже абсолютно ничего хорошего.
Хм. Куда то я в сторону ушел. Сорри, наболело :))