James,
It isn't really all that hard to insure that nothing has changed. As mentioned
by Stefan Tilkov, you can use time stamps or version numbers. Another option
that gives finer grain control is to save a copy of the original data then
construct an update statement like the following:
UPDATE EntityTable SET column1 = newValue
WHERE primaryKey = key AND column1 = originalValue;
Obviously this is also a simple example. So I know that there are problems when
the column count is high. Using a persistence layer that constructs the SQL for
you means that you only have to deal with the concurrency exceptions when they
arise.
--Victor Langelo
James Cook wrote:
> ----- Original Message -----
>
> 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".
