Здравствуйте. Пишу приложение для работы с бд firebird. Пользователей предпологается около 200. И тут появилась проблема с блокировкой редактируемой записи. Т.е. пользователь №1 редактирует запись, в это время пользователь №2 начинает тоже эту запись редактировать. По правильному должно выходить предупреждение что запись редактируется или режим только чтение. Как такое можно сделать? Работа производится на прямую с базой. Конкретного решения не прошу, просто пните меня в нужную сторону. 

ПС про оптимистичные и пессиместичные блокировки читал, как это реализованно в яве толком инфы не нашёл. 
ППС проект уже почти дописан и не желательно что-либо менять в базе.

Блокировки как бы реализуются на уровне базы, типа select for update, все, что выше может только делать их вызов более или менее прозрачным для пользователя.

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

Соответственно надо решить, как минимум, 2-е задачи:
1. Как пометить, что запись взята на редактирование
2. Как быть если кто-то запись взял и "забыл" про неё.

Добавлено через 2 минуты и 24 секунды
По обоим пунктам можно обойтись средствами СУБД, например, введя доп. поле в таблицу (помечая отобранные записи), а также запустив планировщик, который снимает "метрвые" блокировки.
Можно также для этих целей использовать единый класс-контроллер, который будет заниматься почти тем же самым, но тогда вы не сможете дать доступ к базе другим приложениям.

Блокировки я хочу, но толком не понял как их реализовать.
Дополнительное поле очень не желательно.
Работать будут несколько экземпляров программы, на разных компах.

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

2. Вот вам вариант пессимистической блокировки, осуществляемой через JDBC - 


3. Исходите из того, что если вы умеете устанавливать блокировку средствами SQL, то вы умеете это делать и средствами JDBC.  

4. Прежде чем применять пессимистические блокировки продумайте механизм их снятия. 

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

P.S.
Вы уверены, что у вас проблема не с архитектурой приложения?
Обычно должны быть бизнес-правила, при которых не возникает задачи одновременного редактирования одного и того же. Причем эти правила, хотя и реализуются программистом, но закладываются на уровне организации бизнес-процессов, возможно людьми, которые не умеют даже включать компьютер.
А для разруливания теоретической возможности "столкновения интересов" прекрасно работает оптимистическая блокировка, коя не есть физическая блокировка записей, а логическая операция, которая, в своем простейшем виде, состоит в проверке перед записью того, что кто-то другой за это время уже не изменил запись, а если так, то вас или посылает, или предлагается возможность "настоять на своем", или у начальства всплывает сообщение о том, что два барана утром рано озаботились одной и той же работой и надо бы вмешаться в сам процесс...

Это обеспечивается стандартным механизмом транзакций СУБД. Надо делать примерно так:


Придумывать новые поля и проч. не надо - все уже придумано. Погуглите со словами "JDBC transaction" или посмотрите сюда

Это сообщение отредактировал(а) ivanovpv - 3.6.2010, 15:58

hexcom, ваше желание понятно, не понятно что конкретно его вызвало.
объясните чего вы опасаетесь при одновременно редактировании записи? 
это очень важно, от этого будет зависеть решение проблемы  если проблема на самом деле существует 


для понимания:


ivanovpv, по вашему позиция страуса является решением проблемы? (хотя на самом деле еще неясно есть ли она)
ваш пост в данном контексте БРЕД!