Evan,
The Borland AppServer chapter in the recently published J2EE in Practice
book discusses this _very common_ requirement and how it was tackled at AT&T
Unisource. Just to reiterate some of the options currently available to a
J2EE customer.
<extract>
1. Use a stateful session bean to keep a copy of the image sent to the user
for
editing. When the session bean performs the update, it compares the state
of the entity bean with the state it stored in the previous transaction. In
the
event of conflicts, it throws an exception back to the client.
2. Use a stateless session bean that has two parameters: the state read and
the
state edited. The comparison process is exactly the same for the stateful
session bean. Here the client is required to keep track of the state read in
the first transaction.
3. Similar to the previous technique, a version field in the entity bean can
be
used to track changes. When executing the update, the client sends the
edited state object with the version number initially read. Before the
session
bean performs the update, the version number in the entity bean is
compared with the version read in the first transaction. If the version
num-ber
is older then the current one, an exception is thrown. This has better
performance than the previous technique, but still allows for sophisticated
resolution where the state is subsequently compared. The only drawback
is that the database schema must support this new persistent field.
</extract>
There might be others ways to support this in the IIOP world with some
client extensions. But thats for a different mailing list.
regards,
William
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Evan Ireland
Sent: Friday, June 29, 2001 12:12 AM
To: [EMAIL PROTECTED]
Subject: Re: Are Entity Beans(CMP/BMP) really necessary???
Cedric Beust wrote:
>
> 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? :-)
On the contrary, people have been doing this in the two-tier world for
the last ten years or so, and now want to do the same when moving to
EJB CMP :-) The particular customer who asked about this yesterday is
already doing this with BMP.
Thousands of our customers have been doing this with the PowerBuilder
DataWindow, and I am sure many others have done the same using other
vendor's development tools.
> 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" :-)).
The client needs to receive either all the original column values
or a timestamp (or OCC counter column). Let's keep it simple by
choosing a timestamp column.
So the customer does:
myEntity = myHome.findByPrimaryKey(...);
oldState = myEntity.getState();
// oldState contains 'ts' field with original timestamp value
... do some stuff
... arbitrarily many transactions pass
newState = ...
myEntity.update(oldState, newState);
class MyBean
{
...
public Timestamp ts; // one of my CMP fields
public void update(MyState oldState, MyState newState)
{
if (! oldState.ts.equals(ts))
{
_context.setRollbackOnly();
throw suitable exception ...
}
// copy other fields of newState into CMP fields
}
}
Even better would be to allow them just to write:
public void update(MyState newState)
{
ts = newState.ts;
// copy other fields of newState into CMP fields
}
and have us do the checking for them (of course we would need to
retain the old timestamp in the CMP provider code).
> 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
On notification of transaction rollback, possibly re-fetch the data and
advise the user that their update was lost.
> likelihood that it has changed increases over time, so such a scheme is
> probably pointless when looking back more than a couple of transaction.
It's hard to argue with thousands (or even tens of thousands) of
customers that what they are already accustomed to doing in the
2-tier case is pointless.
> 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?
The point is - the gain is in receiving an exception at update time.
Without going to any trouble, they won't find out that they overwrote
the database with inconsistent changes. Database update consistency
can apply beyond an EJB container's transaction boundaries.
> What's your idea to solve thie problem by the way?
See above.
Also, someone who writes EJB books should really sit down and try to
understand all this stuff so as to be able to provide samples for BMP and
CMP usage that don't result in corrupting enterprise databases.
> --
> 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".
--
____________________________________________________________________________
____
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".
===========================================================================
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".
