|
Java форум JavaTalks
форум программистов
|
|
|
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
msam : 38
Новичок
|
 Фев 12, 2012 22:19 |
 |
|
| Подскажите как можно с используя JDBC открыв несколько соединений объеденить их все в одну транзакцию? |
|
|
|
 |
mesier : 693
Постоянный посетитель
Откуда: Новокузнецк
|
| Фев 13, 2012 7:16 |
| |
|
| Цитата: |
| Подскажите как можно с используя JDBC открыв несколько соединений объеденить их все в одну транзакцию? |
Да вроде бы никак.. |
|
|
|
|
Skipy : 4805
Я тут живу!
Откуда: Москва, Россия
|
| Фев 13, 2012 11:28 |
| |
|
| msam писал(а): |
| Подскажите как можно с используя JDBC открыв несколько соединений объеденить их все в одну транзакцию? |
Если имеется в виду транзакция в БД - никак.
Теоретически есть возможность на сервере получить идентификатор транзакции (сервер должен поддерживать распределенные транзакции). Т.е. начать одну транзакцию, получить ID, передать в другое соединение, использовать там для подключения к существующей транзакции. Практически же у меня это не получилось ни с MSSQL 2008, ни с PostgreSQL 8.4.
Если имеется в виду просто транзакция с точки зрения бизнес-логики - смотрите в сторону распределенных транзакций (XADataSource и иже с ним, поддерживающие XA драйвера). Формально это будет несколько разных транзакций - изменения в одном соединении Вы в другом не увидите - но коммит/откат будет синхронным.
_________________
С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других! |
|
|
|
|
msam : 38
Новичок
|
| Фев 13, 2012 12:20 |
| |
|
Спасибо за ответы.
К сожалению нужны именно несколько соединений в одну транзакцию Используем firebird в нем есть так называемые двух двухуровневые распределенные транзакции, сами не пробовали. от XA пришлось отказаться - сильно медленно, по сравнению с JDBC. |
|
|
|
|
aleksandy : 1077
Завсегдатай
|
| Фев 16, 2012 11:02 |
| |
|
| msam писал(а): |
| Подскажите как можно с используя JDBC открыв несколько соединений объеденить их все в одну транзакцию? |
А зачем открывать несколько соединений? Нельзя одно передавать? Что вообще в итоге должно получиться? Может через savepoint-ы можно сэмулировать? |
|
|
|
|
msam : 38
Новичок
|
| Фев 16, 2012 15:47 |
| |
|
| aleksandy писал(а): |
| msam писал(а): |
| Подскажите как можно с используя JDBC открыв несколько соединений объеденить их все в одну транзакцию? |
А зачем открывать несколько соединений? Нельзя одно передавать? Что вообще в итоге должно получиться? Может через savepoint-ы можно сэмулировать? |
Нет не получится. В последствии будут разные физические базы. На счет savepint тоже закрась у меня мысль что этот механизм может пригодиться, где бы его подробное описание взять? Может ли одна savepoint работать для нескольких соединений? |
|
|
|
|
mesier : 693
Постоянный посетитель
Откуда: Новокузнецк
|
| Фев 16, 2012 16:05 |
| |
|
Не покидает ощущение, что автор пытается сгорбатить какой-то жуткий велосипед!
Несколько соединений в одной транзакции.. Разные физические базы.. Боюсь даже представить что может получиться! Не велосипед даже, а скорее какой-то шестикрылый семи%уй..
Поделитесь задачей! Тут на сайте есть люди, я уверен, которые обладают навыками архитекторов. Ведь большинство бизнес-требований уже когда-то кем-то решено - есть множество готовых решений по интеграции, консолидации, репликации, кластеризации.. (О скока умных слов знаю!  )
А то вот выпустите вы своего монстра в продакшн а он в первый же день на банальном дэдлоке заткнется, во смеху-то будет.  |
|
|
|
|
msam : 38
Новичок
|
| Фев 16, 2012 23:42 |
| |
|
| mesier писал(а): |
...
Поделитесь задачей! Тут на сайте есть люди, я уверен, которые обладают навыками архитекторов. Ведь большинство бизнес-требований уже когда-то кем-то решено - есть множество готовых решений по интеграции, консолидации, репликации, кластеризации... |
Пожалуйста, советы люблю.
Немного о себе: более 26 лет занимаюсь разработкой и внедрением комплексных информационных систем управления предприятием. Термин ERP будет близок, но есть еще много чего, документооборот, CRM, PDM и т.д. Все собственной разработки. Речь идет о тысячах рабочих мест .
Задача проста - переписать существующую систему управления, с учетом всех уже известных сложностей.
Начнем с общих требований к системе и к среде разработки.
Масшатабируемость, увеличение производительности всей системы, путем простого увеличения количества компьютеров, на которых работает сервер приложений, база данных. (Велись переговоры с ibm и oracle. Наше предложение продемонстрировать работу на кластерах как то не вызвало никого энтузиазма  ).
Многоплатформенность.
Дистанционная работа.
Возможность работы клиентов на слабых каналах – минимизация объема передаваемой информации.
Бесплатность(по возможности) использованного ПО. Долго искали, кому можно отдать денег за то, что нам нужно, но пока пусто …).
Возможность использования любого SQL сервера, поддерживающего стандарты.
Встроенная версионность. Возможность использования версионности для любого объекта находящегося в системе.
Единая система управления правами : каждый модуль , объект может обладать своим уникальных набором прав.
Встроенная в систему возможность архивирования данных, т.е. создание архивных хранилищ данных доступных при оперативном поиске и не как не влияющих на оперативную работу связанную с изменением данных. Поясню: Есть некий физический придел роста объема одной базы дынных, после которого с ней работать становиться не только не удобно, но совершенно по идиотски используются ресурсы сервера. Зачем например серверу при вставке очередной накладной учитывать, выдачу перчаток 1995 году Хотя для статистики эта информация нужна. По этому решение - другая база .
Невозможность испортить ясную и логичную исходно созданную структуру данных, “специалистами” на местах, делающих некие корректировки системы.
Сохранение простоты и управляемости структурами данных, при неограниченно росте решаемых прикладных задач.
Автономность модулей, форм системы, т.е. полная не зависимость от любых внесенных изменений в другие прикладные формы, модули.
Простота разработки приложений, скорость разработки не ниже чем в delphi , при скромной квалификации кодеров.
Это то, что вспомнилось сегодня вечером, хотя есть ощущение что, что-то забыл
Большинство вопросов решено.
Сейчас запускаем первый прикладной модуль с использованием нашей среды разработки. Решили назвать ее JDF - Java Developer Framework.
Актуальный вопрос это управлений несколькими соединениями в одной транзакции, как я уже писал выше, хотя решение есть, но как то оно мне не нравиться. |
|
|
|
|
mesier : 693
Постоянный посетитель
Откуда: Новокузнецк
|
| Фев 17, 2012 5:46 |
| |
|
Собственный SAP R3 ? 
А чем готовый-то не угодил?
У нас работает.. |
|
|
|
|
msam : 38
Новичок
|
| Фев 17, 2012 8:54 |
| |
|
| mesier писал(а): |
Собственный SAP R3 ?
А чем готовый-то не угодил?
У нас работает.. |
Ага, кое в чем похоже, SAP не устраивал как минимум по двум параметрам: управление производством в нем примитивное и цена. Получалось нужно заплатить для начала 700000$ за 50 рабочих мест и получить то, что работало еще 1998 году. А мест рабочих нужно гораздо больше и терять в функционале да еще за свои деньги, как то странно а потом уже с пользованием среды SAP дописывать то что нужно. |
|
|
|
|
Skipy : 4805
Я тут живу!
Откуда: Москва, Россия
|
| Фев 17, 2012 14:11 |
| |
|
| msam писал(а): |
| Ага, кое в чем похоже, SAP не устраивал как минимум по двум параметрам: управление производством в нем примитивное и цена. Получалось нужно заплатить для начала 700000$ за 50 рабочих мест и получить то, что работало еще 1998 году. А мест рабочих нужно гораздо больше и терять в функционале да еще за свои деньги, как то странно а потом уже с пользованием среды SAP дописывать то что нужно. |
Кроилово ведет в попадалову. Вы с большой вероятностью потратите на разработку существенно больше, и получите то, что работает существенно хуже, чем SAP. Потеряете время, потеряете деньги. Не, решать, конечно, Вам.
P.S. Кстати, Вы так и не объяснили, зачем Вам несколько соединений в одной транзакции. Из кучи общих слов такое требование никак не следует.
_________________
С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других! |
|
|
|
|
msam : 38
Новичок
|
| Фев 17, 2012 15:59 |
| |
|
| Skipy писал(а): |
P.S. Кстати, Вы так и не объяснили, зачем Вам несколько соединений в одной транзакции. Из кучи общих слов такое требование никак не следует. |
Вариантов несколько:
1) это тогда когда физически будут использоваться несколько баз для хранения данных.
2) если использовать заранее подготовленные "PreparedStatement" в которые просто подставить параметры, то скорость работы с базой получается весьма приличной по сравнению с entity в 30 - 100 раз. Речь идет о простых коротких запросах.
Теперь немного о скупости и тд.
Дело даже не в деньгах, деньги есть. Получается что приходят специалисты у которых система умеет меньше, чем та, которая работает уже 12 лет. Сами они могут говорить стандартный набор фраз, не понравилось прежде всего это. В итого получается купить за не слабые денюжки старинную не удобную среду разработки и разбираться с ней самим, дописывая то что нужно? Решили что нет, напишем сами. Прошло 1.5, года почти все работает. Например нет пока еще красивого редактора прав и другие мелочи, основной функционал работает. Прикладные приложения встали в разработку а склад уже запускаем.
Ведь хочется сразу и всего и по возможности дешевле. Как более менее JDF устаканиться, я выложу результат работы. Сама среда предполагается бесплатной. |
|
|
|
|
GlooK : 58
Новичок
Откуда: Самара
|
| Фев 28, 2012 23:08 |
| |
|
Возможно глупость скажу, но может в данном случае применить партиционирование таблиц в самой БД? В ФБ конечно такого нет, зато, к примеру есть в MySQL.
Ну или попробовать сделать пул транзакций - т.е. перед коммитом проверять, что остальные транзакции также готовы к коммиту. Если хоть одна транзакция зафейлилась, делать у всех ролбэк. |
|
|
|
|
Skipy : 4805
Я тут живу!
Откуда: Москва, Россия
|
| Фев 29, 2012 13:28 |
| |
|
| msam писал(а): |
| Skipy писал(а): |
P.S. Кстати, Вы так и не объяснили, зачем Вам несколько соединений в одной транзакции. Из кучи общих слов такое требование никак не следует. |
Вариантов несколько:
1) это тогда когда физически будут использоваться несколько баз для хранения данных.
2) если использовать заранее подготовленные "PreparedStatement" в которые просто подставить параметры, то скорость работы с базой получается весьма приличной по сравнению с entity в 30 - 100 раз. Речь идет о простых коротких запросах. |
Так, стоп. Несколько соединений с разными физическими базами (ну или с одной, но с разными транзакциями внутри соединений) - это принципиально другое. Это XA-транзакции, они поддерживаются большинством производителей. Используется XA-драйвер, который есть для Oracle, MS SQL, Sybase, PostgreSQL совершенно точно. Физически в базах транзакции разные, собраны в одной глобальной распределенной транзакции, менеджер работает по принципу двухфазного коммита. Я говорил об объединении нескольких соединений к одной физической базе в одну физическую транзакцию в этой базе.
А какой отношение к транзакциям в разных базах имеют prepared statements - я, честно сказать, не совсем понял.
_________________
С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других! |
|
|
|
|
|
|
Страница 1 из 1
|
Список форумов
-> Работа с базами данных |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
