Hi Evan,
And thanks for bringing the discussion back on track.
> 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.
This strikes me as not very common, but what the hell, we're not here to
solve real-world problems, are we? :-)
The first problem I see with this is: how many transactions ago are we
looking at for the verification? If you want to be very flexible in your
solution, you have to allow them to refer to an arbitrarily old transaction.
That's already a problem in itself, but you can probably agree on some
proprietary means to hand out transaction identifiers to your client so that
they can refer to them later ("transaction receipt" :-)).
One way to solve this problem would be to take snapshots of the Entity bean
state between each transaction. These snapshots could go back in time
arbitrarily long. Once you have these snapshots, you know what fields were
modified, and also the value they had before and after the transaction.
It's straightforward (with EJB 2.0 anyway) to issue a SELECT query at this
point to verify that the UPDATE won't overwrite stale data.
That being said, I still find your customer's design very suspicious. What
do they intend to do if they find out that the data has changed? Also, the
likelihood that it has changed increases over time, so such a scheme is
probably pointless when looking back more than a couple of transaction.
Better use read-only entity beans otherwise.
How is that different from attempting to UPDATE the data and receiving an
Exception from the container or the database? What do they gain by knowing
ahead of time?
What's your idea to solve thie problem by the way?
--
Cedric
===========================================================================
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".
