"Jonathan K. Weedon" wrote:
>
> 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.
This is useful to a point, but if you want to be able to cache entities
beyond transaction boundaries, then a verifyAllFields approach or
timestamp/counter column is more appropriate.
> 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 ;-)
<vendor>
We beat you to it :-) EAServer 3.6.1 uses all-field-comparison by default.
In fact if you don't want optimistic updates, you have to take the trouble
to specify that during deployment.
</vendor>
I would like to take this discussion a step further, in line with a request
I received yesterday from a customer. We are all now familiar with the
notion of saving original (or timestamp column) values on ejbLoad, and
generating an appropriate WHERE clause to verify that no fields changed
since ejbLoad at the time of ejbStore.
What my customer requested was even more interesting. They are populating
a table on the client with some data retrived from entity beans. The
client now (in a separate transaction) wishes to update one or more
entities (let's say just one). The customer wishes to ensure that the
entity being updated was not changed since the original values were
received by the client (in an earlier transaction).
So what in effect is being requested is that the WHERE clause verification
doesn't use the values retrieved on the ejbLoad call, but instead uses the
values that were received earlier by the client and passed back into the
entity business method that performs an update. All of this with CMP,
of course.
Now I have a fairly simple solution in mind but before I reveal it I
wonder if folks here think that this issue is an interesting one to
discuss, and would be prepared to share design patterns that they are
using (or considering using) with CMP to accomplish this.
> -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".
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
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".
