On Tuesday, October 4, 2016 at 8:18:57 PM UTC+2, Pierre wrote:
>
> oh great i see
> so the two apis speak the same language but they don't communicate ?
>
they do perfectly integrate: the only way it's possible and the way it's
more natural.
> never mindbut better be prudent
>
>
oh great i see
so the two apis speak the same language but they don't communicate ?
never mindbut better be prudent
thanks Niphlod
hopefully everything is under control :) Have you seen the movie
melancholia by lars von trier ?
--
Resources:
- http://web2py.com
-
it's because DBAPI opens a new transaction the same way web2py does.
On Monday, October 3, 2016 at 1:54:20 PM UTC+2, Pierre wrote:
>
> ok, understood.
> now let's go back to the basic situation of a single transaction. you
> suggest I should discard posgresql transaction parameters in the
ok, understood.
now let's go back to the basic situation of a single transaction. you
suggest I should discard posgresql transaction parameters in the first
place ? why is that so ? Is it because this feature isn't supported in
web2py or for a different reason ?
I am not sure yet but I
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 -
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
tl;dr you can't . You ABSOLUTELY can't survive a transaction in different
processes. If you need to control concurrency, implement your own "lock" in
the app (i.e. using a "light" record in a table).
On Friday, September 30, 2016 at 7:30:30 PM UTC+2, Pierre wrote:
>
> Hi,
>
> it's late and the
7 matches
Mail list logo
