> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Frentress
> Sent: Wednesday, March 03, 1999 12:56 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity Bean Management
>
>
> > -----Original Message-----
> > From: Sachin Aggarwal [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 02, 1999 6:07 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Entity Bean Management
> >
> > But what if the user is going through a series of steps where each step
> > requires user interaction and the steps should not be committed till all
> the
> > steps are done. On one hand there's the issue of user going for
> lunch and
> > hanging locks and on the other hand there's the issue of the
> system having
> > commited to the the database only half the steps and user decides to log
> > out.
> >
> > A typical example would be a user looking up a custom order ,
> getting it's
> > custom spec , changing the custom product spec , changing the shipping
> > address on the order and then logging out.
> >
> > I'm being faced with this issue ? would you put these steps as different
> > operations on a session bean ? When would you start the transaction and
> when
> > would you commit it ?
>
> if you truly need to provide concurrent access to an order (which it isn't
> clear that you actually do) then you do have a number of options.
> one option
> is a logical lock whereby you "check-out" the order for editing. another
> option (probably better for your example) is to be more
> optimistic. read the
> order (which has a LastTouched timestamp) without concern for
> locking. when
> the user issues a save operation, begin a transaction to make
> your changes.
> just before applying your changes, see if your timestamp matches the order
> timestamp. if it does, you can safely apply your changes. if the
> timestamps
> don't match, then you apply a business rule. you can of course handle
> logical locking at a finer level but this demonstrates the idea
> well enough.
Actually if I use optimistic concurency ( which I plan to use ) then I
shouldn't even need to bother with reading time stamp etc. I just start the
tx and when I commit it I will get a failure if somebody has changed the
order since I read it and I can handle a retry from there on. I think.
>
> ==================================================================
> =========
> 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".
