CMP performs write-at-commit. That means your update are not written
until the transaction commits, and so are not visible to the database
server within the same transaction. Finders are typically implemented as
SQL statements to the database, so the SQL is not finding a bean which
was not saved yet.
Since this is implementation specific (but you can expect most
implementations to work this way), it's not covered by the spec.
As for always updating the table, CMP should be able to check for
modifications and determine whether or not to update.
arkin
Paul Nicklin wrote:
>
> 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".
