Многопользовательский ввод в базу mySql на Java

Подскажите, пожалуйста, возможен ли осуществитьмногопользовательский вводв mySql-ую базу, используя средства Java.В mySql нет транзакций,есть функция LOCK TABLE, а возможна ли блокировка на уровне записей? И где можно почитать на эту тему? Поделитесь опытом!
заранее большое спасибо!

Ну, почитал я это все ) И у меня появилось, что сказать.

Первое -- EJB стнадарт. Бесспорно. Де-факто -- бесспорно. Обязательность его использования -- весьма спорно. ) Весьма... То, что делает EJB, вполне можно переложить на уровень СУБД. И мы так и делаем. И делаем успешно. И делаем успешно, зная о том, что существуют CMP и JDO. И даже умеем ими пользоваться.

Но все-таик вызываем хранимые процедуры и привет. Не имеем зеркала реляционной модели в памяти приложения. И не нужны никакие ни CMP, ни JDO. Проще это или сложнее -- одинокаво. То, что писали бы Java-программеры, пишут SQL-программеры. У Java-программеров работы не уменьшается -- есть о чем думать.

Теперь про Session Beans. И это второе ) Обязательно ли их использовать -- нет. Ни в коем случае нельзя необоснованно кидаться все через бины гонять. Их надо использовать не потому, что модно, а только если оправдано. Первое необходимое (все понимают, что не достаточное) условие того, что Session Beans не нужны -- отсутствие необходимости контроля транзакций на уровне EJB. Например (только например), транзакции скрыты в хранимых процедурах. Второе необходимое условие -- отсутвие сервисов.

Здесь надо остановиться по-подробнее. Чаще всего, когда EJB не оправданы, Session Beans формируются исходя из UI. UI близок к Use Case'ам, но все-таки всего лишь близок. Самое важное в Session Beans -- сервисы. Каждый бин -- отдельная подсистема, причем очень высокого уровня. Так это должно быть. А что я часто наблюдаю -- сервлет просто делегирует бину выполнение операции. А бин делегирует ее СУБД. Так зачем такое надо. Это не сервис. Сервис -- инкапсуляция непростых алгоритмов, продиктованных устоявшимся бизнесом в реальности. Инкапсуляция в одном вызове (в идеале). А простое 'удалить строчку из БД' -- это не сервис. Сервис -- 'сменить расписание данного поезда на следующее'.

Так вот, если алгоритма нет, или алгоритм реализован в сервлете (и его нет смысла переносить на EJB ради того, чтобы только использовать EJB), то можно инкапсулдировать знание о том, как сделать вызов к БД в отдельном объекте. Я такие объекты называю DAO, хотя это и не совсем DAO.

Сухой остаток моего опуса -- EJB -- стандарт, но не надо пихать его без смазки ) И я прекрасно понимаю, и даже не говорю о том, что, конечно же, все зависит от задачи. Об этом говорить даже не стоит -- само собой разумеется )

Все это я пишу для госпожи Маловой, так как вы, старые перцы, и так в адеквате )

0

Ну почему, мне тоже это интересно. Действительно, а где госпожа Малова?

0

anna_malova сообщите свой емыл

Поддержка транзакций базой данных и многопользовательская работа с этой базой
помоему делитанскому мнению несколько разные вещи, помогите разобраться.
Поддержка транзакций, это когда ,например, есть необходимость чтобы в базу
попали три стейтмента вместе, и только вместе
(делаем, что то типа
beginTransaction;
try {
firstStatement;
secondStatement;
thirdStatement;
} catch(SQLException e){
rollbackTransaction;
} commitTransaction; )

Многопользовательский же ввод в базу это когда нужно чтобы данные занесенные
одним пользователем не затирались другим, правильно ?
хорошие СУБД(Oracle, MS SQL Server, PostgreSQL) реализуют это сами, т.е. если кто то
владеет таблицей в данный момент, то нужно немного подождать.
Если же в проекте используем что то попроще то эту проблему надо решать самому???
И тут помогут менеджеры транзакций... так или не так?

0

Привет.

Многопользовательская работа это когда 'много' (возможно и не одновременно) вводят изменяют данные в базе. Возможно ты
можеш захотеть сделать некоторые изменения транзакционными. Вот и все отличие.
То что ты указал в качестве транзакции полностью ею не является, транзакция должна удовлетворять 4 требованиям, чтобы
назваться ею (у тебя только одно).
А СУБД или Полностью поддерживает транзакции или не полностью.
Есть менеджер соединений он возможно решает проблемы поднятые тобой, но он предназначен для других вещей. Мыло давай свое.

KhasDenis@mail.ru

0

Здравствуйте!
Я снова здесь.-) Спасибо огромное за все Ваши ответы. За то время, пока я все читала, просветилась намного больше, чем за год обучения в университете. И это чистая правда. Вообще, проект - это учеба, а учеба - это проект в моем случае. Ну, два в одном-). Сказать в ответ мне почти нечего, потому что EJB-технологией не владею совсем, и что это такое, узнала большей частью из ваших ответов. Посему пойду учииться дальше и переваривать все, что здесь узнала -) Тут мое мыло спрашивали, да?
anna_malova@hotmail.com - вот.
Напишите мне, пожалуйста, если появятся какие-то идеи. Буду очень, очень признательна. Вы вообще здорово мне помогли, СПАСИБО!
С уважением, г-жа Малова-)))