You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "Smith, Lee [OS-IE]" <LE...@saic.com> on 2004/11/04 11:28:37 UTC
Continuations and cleaning up
Hey All,
New user to cocoon here, and I've got a question about the use of
continuations in flow scripts.
I'll explain my question with the following block of code:
1: function myFunc()
2: {
3: var myDB = Database.getConnection("myPool");
4: myDB.setAutoCommit(false);
5:
6: .. do some work on the connection, don't commit
7:
8: cocoon.sendPageAndWait("confirm_changes.html");
9:
10: if (cocoon.request.getParameter("confirm_changes") == "true")
11: myDB.commit();
12: else
13: myDB.rollback();
14:
15: cocoon.sendPage("change_made.html");
14: }
In this example I get a connection to a database, make some changes and then
allow the user to confirm they are happy with the changes and then depending
upon their response, either commit them or roll them back.
Now this is all fine assuming the user follows the confirmation or
cancellation links on the page - however, assuming there is a menu system on
the confirmation page it is possible for the user to break out of the
continuation without completing it, hence leaving uncommitted changes in the
database.
Is there anyway I can trap the user activating links on the site (assuming
they activate another resource in the current site-map)? I have a feeling I
may be thinking about this in too much of a Java-ish way and there should be
another way I should be doing this :)
I'm expecting somebody to say "Why not let the user confirm any changes
before applying them to the database", well the reason for doing this is it
allows me to trap any errors (ie. things like duplicate keys, or invalid
foreign keys) that show up when you apply the changes to the db and then
show these to the user before I ask them if they are happy with the changes.
Anyway, thanks in advance for any advice :)
Lee
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Continuations and cleaning up
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Smith, Lee [OS-IE] wrote:
> Hey All,
>
> New user to cocoon here, and I've got a question about the use of
> continuations in flow scripts.
>
> I'll explain my question with the following block of code:
>
> 1: function myFunc()
> 2: {
> 3: var myDB = Database.getConnection("myPool");
> 4: myDB.setAutoCommit(false);
> 5:
> 6: .. do some work on the connection, don't commit
> 7:
> 8: cocoon.sendPageAndWait("confirm_changes.html");
> 9:
> 10: if (cocoon.request.getParameter("confirm_changes") == "true")
> 11: myDB.commit();
> 12: else
> 13: myDB.rollback();
> 14:
> 15: cocoon.sendPage("change_made.html");
> 14: }
>
> In this example I get a connection to a database, make some changes and then
> allow the user to confirm they are happy with the changes and then depending
> upon their response, either commit them or roll them back.
>
> Now this is all fine assuming the user follows the confirmation or
> cancellation links on the page - however, assuming there is a menu system on
> the confirmation page it is possible for the user to break out of the
> continuation without completing it, hence leaving uncommitted changes in the
> database.
>
> Is there anyway I can trap the user activating links on the site (assuming
> they activate another resource in the current site-map)? I have a feeling I
> may be thinking about this in too much of a Java-ish way and there should be
> another way I should be doing this :)
>
> I'm expecting somebody to say "Why not let the user confirm any changes
> before applying them to the database", well the reason for doing this is it
> allows me to trap any errors (ie. things like duplicate keys, or invalid
> foreign keys) that show up when you apply the changes to the db and then
> show these to the user before I ask them if they are happy with the changes.
As you might think this is not a good way to go. You should organize your
business logic into services that are separate from user flow. That means you
first you have to ask for user confirmation, then go with the changes. Even if
your service fails to update the database you still can report the error to
the user and send him back to editing to correct the errors:
var error = null;
while( true ) {
form.showForm( "edit-data", bizData );
form.save( bean );
try {
someService.performAction( bean );
cocoon.redirectTo( "mainpage" );
} catch( e ) {
error = e;
}
if ( error != null ) {
cocoon.sendPageAndWait( "errorHasOccured",
{ exception: error} );
}
}
This code loops until the service gets properly executed. Still the user can
follow other link and leave the continuation which in turn will expire after
some time.
No problem witch resource management. No problem with scalability (holding
open connections while user drinks coffee is a BadThing (tm)). Also you can
make your service testable which could be PITA in your approach.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Continuations and cleaning up
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 04/nov/04, alle 11:28, Smith, Lee [OS-IE] ha scritto:
> 3: var myDB = Database.getConnection("myPool");
> 4: myDB.setAutoCommit(false);
> 5:
> 6: .. do some work on the connection, don't commit
> 7:
> 8: cocoon.sendPageAndWait("confirm_changes.html");
> 9:
> 10: if (cocoon.request.getParameter("confirm_changes") == "true")
> 11: myDB.commit();
> 12: else
> 13: myDB.rollback();
> 14:
> 15: cocoon.sendPage("change_made.html");
> 14: }
You should *NEVER* have transactions whose lifetime includes users'
think time. You're just asking for trouble by doing this. There is no
way to guarantee that the commit/rollback code will be called in a
reasonable amount of time.
This is not a problem with Coocon's use of continuations, but is
typical of all web apps. With flowscript it's just easier to fall in
this trap.
Search Google for "optimistic lock". This is also a good starting
point:
http://www.martinfowler.com/eaaCatalog/optimisticOfflineLock.html
Ugo
--
Ugo Cei - http://beblogging.com/