Paul,
The behavior you see here is not indicative of EJB CMP in general, but of
one vendor's implementation.
There are other issue with CMP as it stands though:
1. EJB spec says it is not a good idea to have entity beans represent only a
single rdbms table. Rather it suggests that a bean should be a coarser
grained object whose sub-objects should be modeled as "dependent objects"
not full beans. This is because there is a fair amount of over head with
each bean since they are remotable objects...
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.
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".
