----- Original Message -----
From: Jean-Baptiste Nizet <[EMAIL PROTECTED]>
> In the case of IAS, I'd rather say that this job is the designer/deployer
job,
> since all the work can be done by the container. You just have to choose
the
> right DB transaction isolation level, and one of the additional flags IAS
> provides (updateModifiedFields, updateAllFields, verifyModifiedFields,
> verifyAllFields).
Your assumption is not entirely correct. DB isolation is only going to help
during concurrent writes to the database. The IAS CMP flags do not apply
here either. If a stateless session bean has a method that is intended to
increment a value on a particular entity bean, db isolation doesn't save
you. You are faced with much more work to ensure concurrency.
As a simplified example (pseudocode):
Stateless Session Bean
=======================
public void incrementValue(int pk) {
entityBeanRemote = entityBeanHome.findByPrimaryKey(pk);
int value = entityBeanRemote.getValue();
value++;
entityBeanRemote.setValue(value);
}
(Before anyone suggests that you could move the increment into the entity
bean, or perform the JDBC in a single transaction in the session
bean...don't. This is a simple example, and illustrates the fact that an
entity bean and its dependent objects are most commonly accessed using bulk
accessors as this example shows.)
With IAS, and other optomistic concurrency models, you have to ensure in the
ejbStore() that the originally read value did not change before the db write
takes place. This involves some serious thought on how to ensure this fact,
and db isolation will not save you.
jim
===========================================================================
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".
