JNDI (через которую ты будешь получать SF) у хибера по факту реализована синглетонной мапой.


Читаю Ваши посты, как текст на английском языке... долго перевожу...

JNDI (через которую ты будешь получать SF) у хибера по факту реализована singlenon Map


ага! т.е. мапы шарятся в пределах ClassLoaderа...ага? т.е. тебе надо:
1. использовать одно приложение (ear и war для спринга) для всех твоих компонентов (ejb или spring serv)


Т.е. 2 WAR могут использовать 1 SessionFactory в пределах класслоадера?

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

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


Либо
2. положить hibernate3.jar в класслоадер под класслоадерами тваих приложений. и соответственно начать думать как ты например будешь деплоить и передеплоивать SF


даже не представляю, что значит деплоить SF... В моих проектах сейчас используется HibernateUtil.currentSession(); При деплое в томкате, SF "деплоится" в ThreadLocal static переменную класса HibernateUtil

В Spring можно задеплоить SF как бин, либо юзать JNDI


моё субъективное ИМХО:
jboss, ejb3, один ear - для всех компонентов


Переводя на язык web-app, 1 Томкат для всех web-app... так и есть
EAR, насколько я помню 2.0EJB может включать в себя war, jar архивы и прочью шелупень


(в джейбосе например есть .har для хибера. и он умеет клёво деплоить SF через свой service.xml, ну как persistence unit и persistence archive в JPA)
ну и хибер бы я использовал именно в JPA обёртке. никаких проблем с использованием хибер фич не будет.


С использованием фич хибернейт и без JPA встречаются неожиданности... хорошо что редко.
Киньте линку по JPA где для тупых плз. Раз обертка - вроде как сложностей не должно возникнуть...


про кластеризацию:
одна и та же SessionFactory configuration деплоится на все коробки. Кэш второго уровня синхронизируется между коробками самостоятельно.


Коробка=EAR я правильно понял?

C L2 кэшем интересно, хотя где SessionFactory - там и L2 кэш. Логично.

ещё раз:


распределение компонентов по разным коробкам - это неудачный способ кластеризации. самый распространённый сейчас способ: все компоненты на каждую коробку.


не понял.

Спасибо.