James Cook wrote:
> ----- 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.
>
I don't follow you here. Are all the calls in the above methods done in a single
transaction or not?
If they are, then IAS, using the verifyModifiedFields or verifyAllFields flag,
can detect that the data have been changed by another transaction and throw an
exception instead of updating the value.
If they are not, then of course you're in a big trouble, but a pessimistic
approach won't help you, since the entity bean will only be blocked during the
transaction (which means that while you're doing value++, another transaction
could also modify the bean).
Am I missing something here?
>
> 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".
--
Jean-Baptiste Nizet
[EMAIL PROTECTED]
R&D Engineer, S1 Belgium
Kleine Kloosterstraat, 23
B-1932 Sint-Stevens Woluwe
+32 2 200 45 42
===========================================================================
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".
