Jay Walters wrote:
>
> I wonder why the vendors can't provide examples in their documentation about
> how to do this without corrupting enterprise databases.
Probably the vendors expend so much effort chasing the J2EE bandwagon
that there isn't much time left for this :-)
> Beep. Wake up and smell the coffee here guys.
I really didn't get what you meant by that. Perhaps you can elaborate?
I hope that you don't mean to suggest that J2EE users can afford to
forget the lessons learned over the last 20 years.
> Enough cat fighting. Do you want Sun to adopt PowerBuilder's language
> instead of Java because the 2-tier folks like it? Give Cedric a break.
> None of your readers really believe that Weblogic doesn't work with Oracle.
Hey, give me a break :-) Jonathan is the one trying to push that point.
The point is, it doesn't matter if you are a PB fan or a J2EE convert.
Database consistency may require consideration of optimistic updates
beyond transaction boundaries. If you ignore this, nothing that Cedric
tells you about "Database" cache consistency option is going to help.
You have to accomodate in in your design somehow. The more people that
are aware of this the better. Perhaps you could look more closely at
the usage scenario being discussed instead of trying to cut short a
perfectly valid thread of discussion.
> Cheers
>
> -----Original Message-----
> From: Evan Ireland [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 28, 2001 7:12 PM
> 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".
--
________________________________________________________________________________
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".
