Привет всем,

нагрузка на систему выросла и возникла необходимость в работе c большими объемами данных особенно при работе с SOAP интерфейсом. Поэтому смотрим в сторону старого доброго DAO который имплементируем с помощью spring template ручками прописывая маппинги и sql запросы. Все это крутится в JBoss контактируя с MySQL v5.6

Пока что все неплохо работает, прирост производительности и возможность участвовать в container managed transactions. Единственное что хотелось бы получить еще это трансакционный кэш то есть то что в hibernate зовется 1 level cache.

На данный момент нагуглил обертку как решение:
http://www.ehcache.org/documentation/2.8/integrations/jdbc.html

Кто то сталкивался с проблемой, как решали? Какие фраймворки использовали?

BlazkowiczОтказ от SOAP мог бы быть отличным бустом производительности.
Нет такой возможности, мы в B2B и жесткий контракт это business constraint

bengunГрустненько. Учитывая MySQL, никакой речи о high load не идёт. Поэтому отказ от ORM могу только осуждать. Тем более странным выбором является Spring Template при наличии myBatis и jOOQ.
Да, я понимаю что Вы имеете ввиду, но и с MySQL хочется чтобы быстро было. Поддержка Batch Processing в hibernate никакая, уже много что пробовали. Не для этого сделан был. Что мне даст myBatis и jOOQ конкретно по сравнению с hibernate?

bengun ORM вам вообще никак не мешает участвовать в CMT.
Да, так и работает. Мне было важно чтобы можно было mix mode: hibernate и native sql в одной трансакции миксить так как все сразу переписать не получится.

bengunКеш первого уровня в Hibernate это Session aka Unit of Work. Поэтому я подозреваю что речь таки о втором уровне.
Именно session я и имею ввиду

bengunДа, про лучшее чем EhCache+Terracotta пока не слышал ничего. Как альтернатива у JBoss есть своя реализация кеша тоже с возможностью распределения.
Явки, пароли?

вадяbengunно и с MySQL хочется чтобы быстро былотогда уж надо 5.7.19
Работаем над этим. Обкатывается Galera cluster c 5.7

Petro123жирненьким ваш SOAP
А куда деться, cтандарт. Хорошо что нет SOA

bengunнепонятно, зачем вам хибер, если SOAP будет сверху и закроет все плюшки хибера?
Т.е. у вас на прикладном уровне будет будет только SOAP API?
data access layer независим от того какой интерфейс сверху. У нас интерфейсы:
- GUI (причем с много много AJAX, имплементация интерфейса как у iPhone / iPad парадигмы no-commit-button)
- SOAP
- REST
- пару IoT с hardware boxaми

BlazkowiczНу, если у вас нет большого дерева ассоциаций, а вместо них табличные данные с минимумом связей, то таки да, ORM, в целом, ни к месту будет.
Есть много связей, но нет такого чтобы было чтобы они были нужны. Очень все динамично и зависит от того какие данные нам нужны. Из за это динамичности получается что entity со стандартной аннотацией ассоциаций (lazy,...) хорошо работает только в 20% случаев, для всего остального использовался JPQL и в 5 % native sql.

bengunНе для этого сделан был. Что мне даст myBatis и jOOQ конкретно по сравнению с hibernate?BlazkowiczДаст JDBC, только более интересное чем Spring Template.
Спасибо, гляну myBatis и jOOQ

Blazkowiczbengun Да, так и работает. Мне было важно чтобы можно было mix mode: hibernate и native sql в одной трансакции миксить так как все сразу переписать не получится.
Не понимаю о чем речь. Native SQL в Hibernate и JPA уже много лет поддерживается и работает всё транзакционно.
Хотел выразить следущее: сейчас 140 Entitities в системы. Для каждого entity будет писаться свой DAO. Перевод но новый стэк займет месяцев 10, в это время два стэка должны дружить то есть когда трансакция должна быть одна и таже если например внутри EJB метода мы работает с entities из двух разных стеков.

BlazkowiczНу, тогда кеш тут особо не нужен. Напхали объектов в мапу, в конце транзакции конвертнули в запросы. Опять же, если у вас массивная обработка, то Unit of Work под вопросом.
Так в лоб не получится, бизнес логика разбросана по разным EJBs, сейчас идет все через EntityManager то есть если я прочитал что то то это в сессии сохранилось и читаю тоже самое в других EJBs я читаю из сессии не обращаясь к DB. Конвертирование в запросы не получится хорошо (во всяком случае с hibernate), я сверху описал почему

BlazkowiczНу, раньше он был JBoss TreeCache, сейчас, вроде, просто http://jbosscache.jboss.org/
Спасибо гляну

Blazkowiczbengun, На счет подвязки в текущую транзакцию, надо смотреть детали. В простейшей ситуации, когда у нас только транзакция на уровне БД, вам просто нужно достучаться до текущего Connection средствами менеджера транзакций. Если же транзакцией управляет контейнер, и БД просто XA ресурс, то надо смотреть глубже, как именно выбранный инструмент подцепить в менеджер. Но даже в этом случае, я полагаю, что всё можно свести к банальному получению текущего JDBC Connection из контейнера.
Да, именно так это все и работает. Я просто описывал что было важно, этот пункт уже сделан

Petro123bengun,
Я к тому, что как вы прикрутите сессию хибера к soap, если последнее без состояния?
Вам нужно максимально быстро дать коллекцию в soap. Всё.

Между SOAP и DAO (не важно имплементирован в hibernate, spring templates или чем то еще) есть business logic layer. SOAP объекты похожи но не соответсвуют Hibernate Entities, ну и много SOAP calls бизнес логики а не просто CRUD.

Petro123Да. Допустим, что soap.getAllProducts возвращает один бизне объект, а реально в базе это 100 табличек.
Это сделает iBatis и спринг. Хибер без состояния и без сессии странен. У вас же счас работает без него? Именно потому что без состояния только CRUD и возможен. IMHO

Я думаю мы не понимаем друг друга поэтому развернуто: последнии 6 лет все на hibernate который сконфигурирован как JPA провайдер в JBoss EJB контейнере без Level2 cache. Бизнес логика написана на EJB 3.1 (сначала крутилось в glassfish потом перешли на jboss). Сверху над бизнес логикой слов APIs: GUI, SOAP и тд. Когда идет запрос с API открывается трансакция, за это ответственнен контейнер то есть имеем CMT. Чтобы обработать запрос EJBs друг друга вызывают, точка входа и выхода это тот EJB к которому пришел запрос от API. EntityManager (c hibernate как провайдером) вставляется контейнером при инициализации EJBs:

@PersistenceContext( unitName = "MyWay1" )
private EntityManager em;

Соответственно хибернетовская сессия идет на протяжении трансакции, а в трансакции участвуют несколько EJBs. Если первый какие то данные из DB взял то второй уже берет их из сессии, но это для второго прозрачно. Именно этого и хочу добиться с помощью EhCache и подобного

Petro123Вопрос Usman справедливый. У нас передаются коллекции обычных классов. Думаю, если бы поьребовался большой объем в виде растра, то передавали бы ссылку на хранилище сканов или документов.
Классов чего? Где то надо сделать маппинг с hibernate entity в soap entity. И это для всего дерева связей. И только потом можно все это отдавать клиенту. Но это не проблема

Проблема возникает при CREATE или UPDATE. Прежде чем данные сохранить в базу данных производится их проверка на соответствии бизнес правилам. При этом многое было написано консалтерами раньше через EntityManager и более менее работало. Объемы данных выросли, скорости нехватает. Теперь нам или на JPQL все переписывать или сразу на native sql.

Petro123bengunСоответственно хибернетовская сессия идет на протяжении трансакции, а в трансакции участвуют несколько EJBs. Если первый какие то данные из DB взял то второй уже берет их из сессии, но это для второго прозрачно. Именно этого и хочу добиться с помощью EhCache и подобного
У хибера транзакция обычно равна сессии хибера. Если не так, то покажи.
У хибера при открытии сессии прочитали в БД коллекцию из 10000 объектов и при закрытии сессии забыли о них. При новой сессии опять читаем.
Если не так, то покажи.
Т.е. если в SOAP нет состояния, то при КАЖДОМ вызове метода soap.getAllProducts List<Product> хибер по новой читает 10000 объектов из базы.
Т.к. SOAP метод не помнит тебя при следующем вызове.
Вроде так.
Да это так, именно так я и объяснял. То зачем нужен cache это если я в ejb1 считал 10.000 объектов, то не читаю их уже в у ejb2 и ejb3 который ejb1 вызывает.

bengunОбъемы данных выросли, скорости нехватает.
где узкое место в цифрах?[/quot]
Я уже объяснял, дальше дискутировать не буду. Нужен native sql и какая кэш