[Seaside] transaction engines?
avi at beta4.com
Thu Apr 29 12:04:44 CEST 2004
On Apr 29, 2004, at 2:32 AM, radoslav hodnicak wrote:
> On Thu, 29 Apr 2004, Avi Bryant wrote:
>> But you have multiple copies for a reason, which is that they might
>> have different state. One way or another you have to store that
> Not in my case. I don't allow more than one user to edit an object at
> same time.
How do you ensure this? In particular, how do you know when a user is
done with an object? They might not hit Save or Cancel, they might
just close the browser window and move on...
> I'd need to have some sort of conflict resolution to support
> paralel editing (like user1 changes variable A and user2 changes
> B - if they both commit both changes should be preserverd)
Or you could notify whoever tries to commit second that there was a
problem, and make them redo their change with the other change applied.
> What the user does in one session with forked browsers is their
> problem :-).
The bigger problem within one session is how you implement the Cancel
button. Assume the user has made a few changes and then decides to
abandon them. What do you roll back to? What if they've forked their
browser and are also editing the same object somewhere else? What if
they cancel, then backtrack and try to make changes?
The web, and particularly the back button, makes this kind of problem
truly nasty... my head spins every time I try to think about it.
A pessimistic locking scheme, which is what it sounds like you have,
might actually be the best bet. It could be linked to a Seaside
transaction filter so that if the lock timed out or was stolen by
someone else ("you can't edit this object because bob has the lock; he
hasn't used it for 15 minutes, do you want to take it from him?"), the
edit form that had it before would become inaccessible.
More information about the Seaside