> 2. However the spec does not define how one can specify the mapping for CMP
> beans that included dependent objects in a vendor neutral way. So by
> definition, any CMP implementation that deals with #1 is proprietary.
I believe this is something that EJB 2.0 will address.
arkin
> So, my personal preference is to use an OR mapping technology with BMP. If
> you get tied to a vendor anyway (see #2) you might as well have control over
> things.
>
> As a vendor we can support either approach. But being the control freak that
> I am I personally prefer BMP+OR mapping tool.
>
>
> <vendor partner>
> Take a peek at Cocobase (Thought Inc.). They support BMP, CMP and several
> EJB containers, including GemStone/J of course.
> </vendor partner>
>
> Regards,
>
> -Chris.
>
> > -----Original Message-----
> > From: Paul Nicklin [SMTP:[EMAIL PROTECTED]]
> > Sent: Sunday, February 13, 2000 2:15 PM
> > To: [EMAIL PROTECTED]
> > Subject: Entity Bean Caching
> >
> > Dear All,
> >
> > Is this a weblogic oddity or standard CMP behaviour? I've read lots on CMP
> > in
> > this list and am beginning to doubt it's usefulness in real apps.....
> >
> > In principal, the following is happening: ( WebLogic 4.51, I'm using the
> > Oracle
> > JDBC driver on 8.1 rather than the Weblogic driver on 7.3.4, but I really
> > can't
> > see that making a difference)
> >
> > enter a session been (call by another bean)
> > Use findByPrimaryKey on my container managed bean
> > update a field from NULL to 10 - field is called 'workflowID'
> > << Do some other things here - in the same transaction >>
> > Call FindByWorkflowID (10) on the home interface
> > - no row is found.
> >
> > It would appear that (and I have reasonable evidence)
> > the update is not writing the bean to the DB (that's OK - it's cached)
> > then
> > the findByWorkflowID is going straight to the DB, not scanning the cache.
> > -
> > that's OK too except that it's cached, so it isn't seen
> >
> > Neither approach is wrong in itself, but together they are inconsistent -
> > either
> > you should scan the cache, OR you flush all updates before querying the
> > database.
> >
> > Is the answer to this that I discard CMP? if so why bother providing it -
> > this
> > is the second fundamental fault we've found in CMP.(the other is always
> > updating
> > the table, even if you don't change the bean contents). They may still
> > conform
> > to EJB specs, but they're both quite fundamental....
> >
> > Comments/ Suggestions appreciated !
> >
> > Paul Nicklin
> >
> > ==========================================================================
> > =
> > 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
