Здесь, вероятно, присутствует целая куча технологий и концепций, и вещи начинают становиться довольно запутанными, когда вы начинаете рассматривать многопоточные / многопользовательские приложения.
Как заявил Iassevk, вы должны изучить возможность использования транзакций для обеспечения атомарной природы ваших обновлений - очень низкоуровневым примером будет что-то вроде:
...
con.setAutoCommit(false);
try {
while (rs.next()) {
if (conditions_to_update) {
rs.updateString(...);
rs.updateRow();
}
}
con.setAutoCommit(true);
} catch (Exception ex) {
//log the exception and rollback
con.rollback();
} finally {
con.close();
}
Все обновления будут затем объединены в одну транзакцию. Если какое-либо из обновлений сгенерировало исключение (например, недопустимое значение или сбой соединения в процессе получения результатов), весь лот будет откатан. (Наконец-то добавлено, потому что я чемпион этого; p)
Это, однако, не решит вашу вторую проблему - два конкурирующих метода, пытающихся обновить одну и ту же таблицу - условие гонки. На мой взгляд, здесь есть два основных подхода - у каждого есть свои достоинства и недостатки.
Самый простой подход - Блокировка таблицы - это потребует минимальных изменений кода, но имеет довольно большой недостаток. Работая в предположении, что, как и в большинстве приложений, это больше чтение, чем запись: блокировка таблицы не позволит всем другим пользователям просматривать данные с вероятностью, что код зависнет, ожидая снятия блокировки до истечения времени ожидания соединения пинает и выдает исключение.
Более сложный подход заключается в обеспечении того, чтобы методы для выполнения этих обновлений были реализованы потокобезопасным способом. Для этого:
- Все обновления для этой таблицы проходят через один класс
- Этот класс реализует шаблон Singleton или предоставляет методы обновления как статические методы
- Методы обновления используют ключевое слово Synchronized , чтобы предотвратить состояние гонки