I couldn't agree more with Wendy. But, as with more things, it comes
down to your application.
I work at a large financial institution, so I deal with these types of
situations quite a bit. It all depends on what is being edited.
If we are talking about something like, say, a fund load fee
On 11/1/05, Murray Collingwood <[EMAIL PROTECTED]> wrote:
> The scenario is very simple:
>
> 1. User A clicks an "edit" option to edit a record.
> 2. While user A is editing the record user B clicks the same "edit" option
> 3. Both users are now editing the same record (or so they think)
> 4. User
I agree with Jason's assertion 100%.
Your best bet on the web is record versioning.
Larry
On 11/1/05, Jason King <[EMAIL PROTECTED]> wrote:
> This isn't a struts question so much as a persistence layer question.
> There are several approaches you can use depending on your data and your
> users.
This isn't a struts question so much as a persistence layer question.
There are several approaches you can use depending on your data and your
users.
For infrequently updated tables you can hope for the best and probably
be safe.
If you're in an EJB world the EBJ layer takes care of that (I th
For web applications, I tend to think that the more appropriate
approach is (what I know to be called) optimistic locking. When a
user edits a record, I keep track of the update timestamp (or even
better, an update sequence number) of the record selected. This value
gets sent back when the user a
5 matches
Mail list logo
