Krish,
Actually, with the advent of EJB 2.0, you can go a few steps further.
As you say, in our current product we have quite a few options, including
verifying no fields, verifying all modified fields, or verifying all fields. The
reason we provided all three options, is that in EJB 1.1 the persistence
manager (PM) does not know which fields were actually used in the current
transaction. The various modes approximate this knowledge.
With EJB 2.0, the PM does know which fields were used in the transaction.
That is, the PM is called either when a field is read (via a getter method) or
when a field is written (via a setter method).
So now, with EJB 2.0, it is possible to do a tuned, verified update, such as:
UPDATE <some_table> SET (only_changed_fields) WHERE
<all_values_read_during_transaction>
That is, you can do the verification only on the fields that were actually
read in the given transaction, instead of on all fields.
Then, you can actually go one step futher, and observe that if a particular
field was written _prior_ to being read, then there is no reason to verify
its previous value. Such "blind" writes do not need to be verified.
All of this should look familiar to anyone who understand how compilers
do various "peep-hole" optimizations.
P.S., regarding your suggestion of making verified updates the default
behavior, it is noted ;-)
-jkw
Krishnan Subramanian wrote:
> Jonathan,
>
> I'm enjoying the discussion - but on the topic of verified
> updates, maybe its an idea in the Borland AppServer (next
> release?) to set the default optimistic concurrency behavior to:
> "VerifyAllFields" that performs an update along the
> lines of:
> "UPDATE <some_table> SET (only_changed_fields) WHERE
> <all_table_column_values_are_values_read_in_at_start_of_transaction>"
>
> instead of the current default "UpdateModifiedFields" which
> performs an update along the lines of:
> "UPDATE <some_table> SET (only_changed_fields) WHERE
> <primary_key_is_some_value>"
>
> I would certainly prefer the former to be the default over the (current)
> latter setting.
>
> -krish
>
> > Cedric,
> >
> > Actually, I believe you provide the following:
> >
> > Exclusive concurrency (pessimistic locking at the container level)
--
Jonathan K. Weedon: Architect
VisiBroker, Borland AppServer
Register now for the 12th Annual Borland Conference: July 21-25 in
Long Beach, California. BorCon is the best place to learn about award
winning technologies for implementing e-business. Register today!
http://www.borland.com/conf2001/
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended
recipient of this e-mail, you are hereby notified that any
dissemination, distribution or copying of this e-mail, and any
attachments thereto, is strictly prohibited. If you have received
this e-mail in error, please immediately and permanently delete the
original and any copy of any e-mail and any printout thereof.
===========================================================================
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".
