[Seaside] transaction engines?

[Avi Bryant]

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 
>> state.
>
> Not in my case. I don't allow more than one user to edit an object at 
> the
> 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 
> variable
> 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.

Hmmmm.

Avi