Comments 10
Хочется больше узнать о поддержке типа данных uuid. В том числе и в качестве primary key.
В последнее время заинтересовался, и встретился с проблемой — существуют тысячи реализаций одного и того же, с десятками развиваемых веток в границах даже одного наименования.
Книг — тоже сотни, и создается впечатление, что разобраться в них может только человек, который уже прочел их.
Потому: Не затруднит ли вас опубликовать Ваш ответ на вопрос:
Не могли бы Вы посоветовать с чего учить современную Java EE и близкие технологии?
Книг — тоже сотни, и создается впечатление, что разобраться в них может только человек, который уже прочел их.
Потому: Не затруднит ли вас опубликовать Ваш ответ на вопрос:
Не могли бы Вы посоветовать с чего учить современную Java EE и близкие технологии?
Самый, думаю, правильный ответ — идти работать в этой сфере. Желательно не на поддержке старых проектов, а на вновь стартующих. И все придет :-)
Из близких технологий очень удобны фреймворки типа Grails и Spring. Во всяком случае, это хорошая точка входа в java для веба, а оттуда и до J2EE недалеко. Тем более что Spring, насколько я понимаю, весьма тесно может быть интегрирован с J2EE-стеком
JavaEE учить с JSF, EJB, JPA и WebBeans.
Близкие технологии — со Spring, GWT и IBatis
Близкие технологии — со Spring, GWT и IBatis
Если английским более-менее то вот статья Java Enterprise Development — 2010 style.
Есть такая задача.
Имеется комплекс ПО по схеме трёхзвенка.
Толстые клиенты общаются с OSGI-сервером, он, в свою очередь, общается с БД
В качестве ORM избрали Hibernate.
Чтобы не тянуть все зависимости объекта сразу, сделали загрузку ленивой.
Но ленивая загрузка работает только в пределах одной сессии, что не очень хорошо.
Если между средним звеном и БД сессию ещё можно удерживать открытой, то клиентские сессии имеют свойство истекать.
В итоге, получаем исключения ленивой инициализации.
Чтобы обойти данный недочёт, пришлось в среднем звене реализовать собственный кэш.
Конечно, возможно, что у нас и архитектура страдает, но я также слышал, что JPA, вроде как, лишён проблем ленивой инициализации.
Я так понимаю, там свой внутренний кэш?
Имеется комплекс ПО по схеме трёхзвенка.
Толстые клиенты общаются с OSGI-сервером, он, в свою очередь, общается с БД
В качестве ORM избрали Hibernate.
Чтобы не тянуть все зависимости объекта сразу, сделали загрузку ленивой.
Но ленивая загрузка работает только в пределах одной сессии, что не очень хорошо.
Если между средним звеном и БД сессию ещё можно удерживать открытой, то клиентские сессии имеют свойство истекать.
В итоге, получаем исключения ленивой инициализации.
Чтобы обойти данный недочёт, пришлось в среднем звене реализовать собственный кэш.
Конечно, возможно, что у нас и архитектура страдает, но я также слышал, что JPA, вроде как, лишён проблем ленивой инициализации.
Я так понимаю, там свой внутренний кэш?
Sign up to leave a comment.
Java EE 6. Обзор JPA 2.0, часть 1: Введение