William,
Thanks for the pointer to the new book.
I am glad that someone appreciates that this is a common rather than
academic requirement. I worry sometimes about all those entrprise
databases being messed up by EJB programmers who think their CMP
engine "takes care of everything". Leaving optimistic concurrency
control up to the DBMS is clearly a poor choice in many scenarios.
William Louth wrote:
>
> 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".
--
________________________________________________________________________________
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".
