> OK Thomas - I found all specific J2EE classes in the OJB source
> distribution.
> I will check the code to have strong understanding.
> But last question - certainly a stupid one - I'm a new OJB user !-) :
> Why there is a specific ODMGJ2EEFactory and not a J2EE specific
> PersistenceBrokerFactory.
In older version of OJB we had one. After some refactorings
we have to re-implement that.
Currently there is only early beta version supports the ODMG api.
We struggle with some details.
Long-term objective is a JCA implementation for OJB.
regards,
Armin
>
> Christophe
>
> -----Original Message-----
> From: Mahler Thomas [mailto:[EMAIL PROTECTED]]
> Sent: vendredi 27 septembre 2002 11:29
> To: 'OJB Users List'
> Subject: AW: OJB/JDO in a EJB context
>
>
> Hi,
> >
> >
> > ok - I'm completly agree with you. Now, I need more technical
details
> > because I'm a new OBJ user.
> >
> > We are agree that the "EJB/OJB integration design pattern" is :
> >
> > Session beans which are accessing direclty OJB broker(s)
> > without entity bean
> > usage.
>
> +1
>
> > My first reflexion expose me to 2 different scenarios :
> > 1. Using OBJ in client/server mode. Sessions beans are "OJB
> > clients" and
> > they uses different remote OJB servers. Load balancing, synchro are
> > completly managed by OJB servers. I'm not motivate by this
> > approach for a
> > EJB integration. and you ?
>
> this approach is somewhat "diametral" to EJB concepts. Thus not
everyone
> will like it although it will work fine.
>
> > 2. Session beans want to call local "OJB data objects". I
> > don't see how to
> > integrate something like a "PersistenceBrokerServer" in a
> > J2EE server. Can
> > you point me to usefull info ? How to support clustering, data
cache,
> > connection pool ... in this case ?
> >
>
> It's not necessary to work with PersistenceBrokerServers.
> You can just run each EJB Server in OJB singlevm mode.
>
> By using optimistic locking (and the distributed Lockmanager for
pessimistic
> locking for ODMG transactions)
> you can properly synchronize all EJB SessionBeans running on multiple
EJB
> servers.
>
> > 3. (?)
>
> Just keep things as simple as possible. Of course it's possible to run
an
> EJB cluster against an OJB server cluster. But this is only necessary
in
> maximum load scenarios.
>
> >
> > I have to make a demo application and a small doc for my
> > customer. If you
> > want I will send it to this mailing list. What do you think
> > about that ? It
> > should be nice to find this design pattern in the OJB doc.
> >
>
> Great! All such "cook books", "white papers", "best practise" reports
are
> most welcome and we will integrate them into our documentation !
>
> Thanks,
> Thomas
>
> > Regards,
> > Christophe
> >
> > -----Original Message-----
> > From: Mahler Thomas [mailto:[EMAIL PROTECTED]]
> > Sent: vendredi 27 septembre 2002 9:35
> > To: 'OJB Users List'
> > Subject: AW: OJB/JDO in a EJB context
> >
> >
> > Hi,
> >
> > > -----Original Message-----
> > > From: Thomas Mahler [mailto:[EMAIL PROTECTED]]
> > > Sent: jeudi 26 septembre 2002 19:10
> > > To: OJB Users List
> > > Subject: Re: OJB/JDO in a EJB context
> > >
> > >
> > >
> > > >Do you expect SUN to admit that entity beans are an
> > obsolete concept?
> > >
> > > No - And you personnaly, do you admit that the entity beans
> > > are obsolete ?
> > >
> >
> > Sure! The failure of EJB entity beans
> > (Performance, inheritance hierarchies, ugly finder code)
> > in one of my customer projects was one of the main reasons to
> > start the OJB
> > project!
> >
> > cheers,
> > Thomas
> >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
