[Seaside] transaction engines?

[radoslav hodnicak]

On Thu, 29 Apr 2004, Avi Bryant wrote:

> 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'm not running this in production yet so I can't safely say it works)
Yeah... what I've tried is to have locking like you describe (without the
possibility to 'steal' locks though) and using short session timeouts to
handle the closed browser window case (locks get released when session
expires).  However the users hate it when session expires while they have
the browser open (I hate it too) - they even leave computers running over
night so I've basically removed the standard seaside session timeout now.

Instead, I'm using a small iframe that has meta refresh, providing kind of
ping back to server. When the user closes the browser ping won't come
anymore and the session can be expired. It would work even better if I
didn't have to support IE - in IE when you hit the back button you get the
previous iframe and not the previous page. I must say that IE literally
killed many ideas I've had during development (that worked in opera and
mozilla) and so far has been the biggest roadblock in my work. Yay M$

I'm assuming that while the browser is open and the user is in an editor,
he has the lock. It's an intranet app, if another user badly needs to edit
it too they can phone eachother or whatever.

> 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?

I'm not sure the idea of forking browser even occured to any of the people
who use the app... and the answer to these questions is probably "I won't
spend any energy on making it to do the right thing(TM) (now)". The
current version doesn't work with forked browsers too and nobody
complained yet.

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

Yeah.. didn't the guy who invented www and wrote the first browser get an
award recently? :-)

rado
-- 
pgp.mit.edu  0x30DEBAE6  12EE FED5 D5B1 77ED 5637 EB77 2A5F 22F9 30DE BAE6