> -----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.
===========================================================================
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".
