> > * Entity Beans (CMP)
> > - I should not use these if the underlying database is being updated by
> > both
> > the EJB and my non-EJB systems, due to Data dis-integrity issues caused
> > by
> > "out-of-synch" cache.
> >
> Not necessarily true. If an EJB implementation caches in this manner, you
> should be able to set caching policies to selectively turn such caching off.
True and not true. An entity is held in memory, so by definition it can
be out of synch with the database. You can lock it before doing an
update, and a good EJB server can do that for you. Such an EJB server
can also track dirtyness for you and make sure your entity bean is
uptodate before you access it, or you can re-load it to guarantee that.
Check which EJB server you're using first.
> > * Entity Beans (BMP)
> > - I should use a non-cacheing implementation, unless I can guarantee
> > synchronization with the updates generated by the non-EJB systems on the
> > underlying DBMS.
> >
> Same comment as per CMP. Beans will synch with datasource state at
> transaction boundaries (per the spec).
This is pretty much up to you, which is why I would recommend using CMP.
> > * Session Beans
> > - I can use JDBC inside the session bean. This is essentially a BMP
> > without
> > a Finder Method.
> >
> Not really true at all. A session bean does not represent a persistent
> entity, but rather represents a "service".
In a session bean you will load the data, update it and store it, or you
will update it directly (SQL UPDATE). You can control the scope and
guarantee such updates always occur inside a transaction. This is what I
would recommend to do, unless you like favor the simplicity of entity
beans.
arkin
>
> > I have total control over the Business Interface(s) offered
> > by my Session Bean. I can use a seperate interface for each role played by
> > my session bean.
> >
> > I'm tending toward the Session Bean approach for the following reasons:
> > 1. I have full control over the Interface(s) offered by the Bean. From a
> > multiple release cycle, as my deat requirements change, this allows me to
> > keep prior interfaces available without being impacted from business
> > domain
> > type changes.
> >
> > 2. I don't want any Session Beans other than ours accessing the database.
> > I
> > could rely on administrative security on Entity Beans, but the Session
> > Bean
> > approach seems to ensure that the architecture is not comprimised, where
> > the
> > Entity Bean approach allows un-informed administrators to grant access to
> > my
> > entity beans potentially comprimising the architecture. Before long there
> > will be client UI's directly calling my Entity Beans. Since my Business
> > has
> > been involved in many acquisitions, my Business domain types are often
> > impacted. This appears to me to have a ripple effect into the Interface of
> > any Entity Beans that I build. Thus due to the cohesion created by client
> > access the potential change impact on consumers of my entity bean seems
> > very
> > large.
> >
> > Am I missing something?
> > David Marshall
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Thousands of Stores. Millions of Products. All in one place.
> > Yahoo! Shopping: http://shopping.yahoo.com
> >
> > ==========================================================================
> > =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
