ha: yep, the logic is totally flawed. You can't be sure your task has been correctly processed just by queueing it. The task DOESN'T obviously run in the same transaction the webpage displaying the form is.
On Thursday, September 29, 2016 at 5:54:20 PM UTC+2, Pierre wrote: > > very confusing situation > problem has been addressed long time ago: > > > https://groups.google.com/forum/?fromgroups#!topicsearchin/web2py/race$20condition;context-place=forum/web2py/web2py/Z581Pk3RCYI/web2py/Z581Pk3RCYI > > what I observe is that transaction logic doesn't work as expected in the > following circonstance : > > *controller:* > > def func(): > form = SQLFORM(db.taba,.......) > if form.process().accepted: > scheduler.queue_task(tska,..........), > redirect(URL(.......) > elif form.errors: > . > . > else: > return dict(form=form) > > if task tska raises an exception (violate unique key constraint) there's > no roll-back and still I get a new record in db.taba > > Is there a generic approach to deal with such overhead problems ? i am > starting to worry a lot.......where's the tunnel exit ? > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
