Mike Williams wrote:
> We have a servlet (S) that calls a session-bean (A) to perform an update.
> Bean A uses an entity-bean (E) to update the status of a database entity
> (let's call it Thing), then calls another session-bean (B) to get a list of
> Things with a particular status. Bean B accesses the database directly,
> using JDBC.
>
> We're expecting the Thing that was just updated to be included in this list,
> but it's not. Seems that the problem is that the EJB container (WebLogic)
> does not call E.ejbStore() before B does it's query. The EJB spec suggests
> that this is quite normal behaviour ... just a shame that we didn't
> understand it before.
WebLogic has a setting, delayUpdatesUntilEndOfTx, that you set
in an entity bean's deployment descriptor, in the
environmentProperties section. From the WebLogic docs:
"This optional optimization affects when changes to a bean's
state are propagated to the persistent store. If the property
is set to "true" (the default), updates of the persistent store
of all beans in the transaction will be performed at the end of
the transaction. If this is set to "false", the update of a
bean's persistent store will be performed at the conclusion of
each method invoke. "
Setting this to false may solve your problem so that the entity
bean updates are visible to the select * in bean B. It may,
however adversely affect overall performance if the extra
stores cause more database activity. I haven't played with it
enough to offer a more specific recommendation.
-Paul Hodgetts
===========================================================================
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".
