Not sure, but I think finders in WL always select from the DB and
disregarding any entities on the cache. When iterating through the fetched
rows and creating beans, this data will write over the same entity on the
cache (if not in a transaction at the time), since this data is assumed to
be "fresher".
Some sneaky ways I think one could test this:
* Digging into the container generated code and put in printlns at
appropriate places including a counter on the number of rows returned.
* Using the isModifedMethod attribtue of an entity's deployment
descriptor, DO NOT change the bean to "modified = true" after a set of an
attribute. This will prevent the change on a cached entity bean from
getting stored in the DB. Then, perform your finder and get the attribute
you just modified. If it is the DB's value, the finder automatically
re-writes over the cached bean, if not, the cached bean stays put!
* Also, enable your jdbc.log file to see JDBC statements that the
server is calling.
Jason
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Robert Patrick
Sent: Monday, February 14, 2000 12:36 PM
To: [EMAIL PROTECTED]
Subject: Re: Entity Bean Caching
Paul,
As Assaf points out, this is because, by default, WLS CMP caches all entity
bean updates until commit time. You can turn this off by setting the
delayUpdatesUntilEndOfTx property in the deployment descriptor to false.
Hope this helps,
Robert
At 07:15 PM 2/13/00 +0000, 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".
===========================================================================
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".
