Всем доброго времени суток!

При вставке/удалении квитанции в одну таблицу мне нужно прибавлять/вычитать балланс клиента в другой таблице. Нужно также сихронизировать эти действия (в случае одновременного изменения), т.е. должна одна транзакция выполнить действия по изменению, а затем уже должна приступать вторая и т.д. Как такое лучше сделать? Триггеры пойдут? 
Я использую MySQL 5, Hibernate 3.

Заранее спасибо за советы!

https://www.hibernate.org/42.html
Да можно просто нативной поддержкой транзакций в hibernate.
а-ля

try {
    tx.begin();
    изменяем один объект
    изменяем другой объект по результатам первого
    tx.commit();
} catch (Exceptio e) {
    tx.rollbak();
}

PS:  но тут основное, на мой взгляд, - ложить в транзакции максимально атомизированные действия, иначе можно довольно быстро наткнуться на transaction deadlocks.

Это сообщение отредактировал(а) afon - 23.1.2010, 19:13

В общем я понял что лучше далать через Hibernate?

vns955, 

Рекомендую использовать хранимую процедуру (они поддерживаются в MySQL).

Вы бы не могли аргументировать? Например - процедура будет быстрее кода, или будет сама транзактить - лочить, следить за потоками, разлочивать, смотреть, чтоб никто не вставил в таблицу данные, пока из нее читают в момент транзакции и тп.. Мне вот тоже интересно.

"Процедура быстрее кода" - я думаю, что вы имели в виду не быстрее кода, а быстрее непосредственного выполнения insert or update or delete на стороне клиента?

В принципе да, есть случаи, думаю довольно частые, когда будет быстрее и значительно, например, нам надо перед вставкой какой либо записи произвести выборку из других таблиц, чтобы проверить правомочность вставки и т.п.
В случае процедуры эти данные не придется гонять по сети.

Вот остальные аргументы:
1. Ценность данных во много раз превосходит ценность софта с ними работающего, включая и вид СУБД, но последняя кардинально обновляется гораздо реже, чем прикладной софт.
Поэтому логично чтобы за их целостность и не противоречивость отвечала СУБД, как:
- менее подверженный изменениям софт

- как специализированный на работе с данными софт, имеющий максимально заточенные для этого способы

- как ежедневно проверяемый на свою надежность и скорость работы с данными сотнями и миллионами пользователей во всем мире.


2. Я за максимально объектный подход, поэтому если СУБД совершенно прозрачно может предоставить мне метод типа createNewOrganization(NewOrgName ...), то и хочу вызывать этот метод, а не разбираться в том вставляются ли при этом данные в таблицу пользователей, организаций, назначения роли пользователю с использованием роли по умолчанию, при этом используется линк к другой базе (если она стала распределенной), как оформляется начало и окончание этой распределенной транзакции и т.д. и т.п.

Вместо этого я получаю нормальный JAVA подход - вызвал процедуру, причем именно из того "класса", который максимально для этого предназначен и она мне все сделала как надо.

Какая альтернатива?
Элементарно, например, берем Hibernate, оборачиваем все в DAO и там инкапсулируем ту же функциональность, на самом деле получаем практически ту же процедуру, но работающую зачастую менее эффективно.

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

А вот чем: 
- На самом деле у нас уже есть "класс", который отвечает за работу - это, грубо говоря, СУБД, ага такая вся из себя с необъектно ориентированными процедурами.
Я не вижу смысла дублировать его работу.

- Если мне придет в голову сменить версию сервера приложений, используемый язык или платформу,  в случае, когда возможности СУБД используются максимально, это произойдет довольно спокойно, т.к. неизбежные глюки хотя и попьют крови, но с нашими драгоценными данными ничего страшного сделать не смогут (ну разве что, если просто туда вводить ложную информацию).

- Если, бЯда, мне таки придется перейти под другую СУБД и т.п., то у JAVA программиста голова болеть особо не будет он и понятия не имеет о том, что у меня теперь другое число таблиц, кардинально изменилась их структура, наименование, вида блокировок, методы контроля доступа ...
Максимум что "бедолаге" придется поправить так это синтаксис вызова метода.
Да и то, вот тут-то как раз DAO и облегчит нам задачу, только его обязанность будет не заново все update и select проверять и изобретать, а просто динамически менять синтаксис в зависимости от версии базы (это если мы решили, что должны теперь иметь возможность работать с несколькими разными СУБД).

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

- Хороший JAVA программист, работающий с базами, данных должен знать SQL и основные особенности базы, но он обычно даже рядом не DBA и понятия не имеет о куче нюансов.
Мне кажется что пусть уж DBA разбирается со своими реверсивными и bitmap индексами, занимается партиционированием, копанием в планах запросов, типах блокировок, FGAC, кучах, буферах, сегментах отката и т.п.

Могу еще долго продолжать, но не уверен, что это вам интересно, если да, то с удовольствием "поговорим".

В сухом остатке лозунги дня : 
- я согласен с Томом Кайтом - никаких insert, update и delete на стороне внешнего приложения;

- используем настоящий высокоуровневый API при общении с СУБД, а не работаем самопальным базописателем;

- я очень благодарен разработчикам Hibernate, но использовать  его возможности я буду по принципу - если этого нет/крайне неудобно в СУБД или вообще не её дело,  а не по принципу - освоил? ну вот и валяй;

- СУБД надо использовать как СУБД, а не как склад данных с 4-мя пресловутыми CRUD;

- работу DBA должен выполнять DBA, а не Hibernate/JPA вкупе с JAVA программером, если вы один в 2-х лицах, то хотя бы четко разделяйте, когда вы одна личность, а когда другая. 

- средства отвечающие за целостность и безопасность данных должны храниться вместе с ними, переведя на объектно-ориентированный язык, - данные должны храниться в классе, который с ними манипулирует и наоборот. В данном случае данные лежат в СУБД и именно она обязана с ними работать.

- долой программы написанные так, что работают с любой СУБД, это все равно, что купить костюм 60 размера, который могут одеть все. 
 

Ого  любят местные форумчане давить интеллектом.
Во-первых, большое спасибо. Аргументы принимаются и многие, как разумные   Со многим согласен. 
Во-вторых, с костюмом 60-го размера вы перегнули. Слегка так. Надо было хотя бы 56-й брать. 

Теперь по теме: 
Мне кажется, что вы смотрите на дело с точки зрения работника (или владельца-профессионала, не знаю) большой компании с огромадным enterprise приложением, раз у вас программер занимается программами а dba занимается базами. С этой позиции все, что вы сказали, очень верно. Одноко с позиции небольшой компании из несколькольких программистов, которые по совместительству еще и архитекторы, и базописатели и тд - практически все сказанное - не верно, кроме бесспорного выигрыша скорости работы процедуры против скорости обработки данных в коде программы при условии действительно серьезной нагрузки. В маленькой компании мы можем захотеть перейти на другую rdbms и сделать это в течение одного рабочего дня без потерь и страданий.  При раздельном подходе нам потребуется серьезный специалист в области новой db. Кроме того этот переход будет проходить не один день, а месяц, как минимум.  Это к слову о "спасибо hibernate, но ..." и к теме унификации. Мне к примеру очень нравится hql, я просто тащусь от него. А писать целые процедуры руками в базе... лень. Но это к слову. 

Все остальное, что я смогу сказать, будет не по теме, а давить интеллектом я не умею  Спасибо за аргументы. 

Вот задача типичная для триггера: при превышении балланса должна блокироваться запись кустомера, т.е. поле blocked должно стать true. А через хибернейт мне кажется делать муторно  :( 

afon, 
А никто серебряных пуль и не предлагает, если у нас телефонный справочник ДЭЗов нашего городка, то, наверное, имеет смысл хранить данные в "любой" базе, или даже в xml файле. 

Но только при этом надо заранее заложиться на то, что к нашим данным будет  доступ только из нашей программы и  данные никогда и никому более не понадобятся за ее пределами, да и жить будут не сильно дольше, чем срок, когда наш JAVA станет чем-то экзотическим типа ФОРТА или КОБОЛа (на последнем куча унаследованного софта, посмотрите, как матюкаются нынешние его владельцы и что-то, тем не менее, не видно очереди желающих его выучить), что при нынешних модных веяниях может произойти несколько быстрее, чем нам бы этого хотелось.

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

Я бы просто - напросто использовал что-нибудь типа Oracle Express и тем самым развязал бы себе руки на возможное развитие и процветание своей программки.
А раз вы такие все из себя "мелкие", то и использовал бы не 80% возможностей ORACLE, а 20%.

И вообще, чем меньше коллектив, тем строже надо следить за "хотелками" - вы же монстров бьете ценой и оперативностью, а если будете менять СУБД как перчатки по "своему хотению божию велению", даже если "цена" вопроса будет: "поставить, да потестить ..."


Дело, разумеется, ваше, но я как раз вплотную столкнулся с тем, когда при внедрении КИС кучу хороших в общем-то программ приходится выкидывать, а  данные с потом и кровью из них выковыривать и только потому, что создатели программ в свое время скромно посчитали себя мелкими и незначительными, а данные не долго живущими.

 Ну так каждой задаче своя реализация 

carper, я бы и хотел углубиться в тему, да не вижу смысла.  Мы и так наоффтопили, больше не хочется. Иначе будем говорить каждый со своей колокольни и оба ни о чем.

 
А в этом случае проблем с кешами не будет? Ну что хибернейт не увидит изменений и я буду ловить старые данные.