a transaction is live from the first command you execute AFTER the first commit() or rollback(). Web2py automatically commit() at the end of a request, or rollback() in case an error occurred. Everything runs separated in each thread (which means every thread runs its own transaction) and - usually - web2py maps a single thread on a single request. Even an ajax request from the same page runs in a separate transaction. Everything is consistent in the smallest "frame" http can assure: a web request/response cycle. Everything that runs in separate processes can't share the same transaction. When you queue you task in the controller, the action of queueing runs in the same transaction of the request that posted the form. When the action is executed in the scheduler, which is an external process, it runs in its own transaction, completely decoupled from the web ones.
So, again, don't even think to fiddle with postgresql parameters or try to make two python processes to work in the same transaction: it's a no-go. You need to redesign your app's workflow to coincide with your mind-model of what should happen. Welcome to coder's world ^_^ On Friday, September 30, 2016 at 11:56:11 PM UTC+2, Pierre wrote: > > > what's are the situations where I can't survive a transaction ? do you > mean queueing tasks in a controller function ? > > how do I work this out in a single process action? > > > > > > > > > > > > > -- 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.
