<div dir="ltr"><div class="gmail_extra">I mean, that we should have explicitly wrapped http handlers. For example:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">@transaction</div><div class="gmail_extra">def PUT(...):</div><div class="gmail_extra">  ...</div><div class="gmail_extra"><br></div><div class="gmail_extra">We don't need transactions, for example, in GET methods.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I propose to rid of complex data flows in our code. Code with 'commit' call inside the the method should be split into independent units.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I like the solution with sending tasks to Astute at the end of handler execution.</div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, May 6, 2015 at 12:57 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> First of all I propose to wrap HTTP handlers by begin/commit/rollback<br>
<br>
</span>I don't know what you are talking about, but we do wrap handlers in<br>
transaction for a long time. Here's the code<br>
<a href="https://github.com/stackforge/fuel-web/blob/2de3806128f398d192d7e31f4ca3af571afeb0b2/nailgun/nailgun/api/v1/handlers/base.py#L53-L84" target="_blank">https://github.com/stackforge/fuel-web/blob/2de3806128f398d192d7e31f4ca3af571afeb0b2/nailgun/nailgun/api/v1/handlers/base.py#L53-L84</a><br>
<br>
The issue is that we sometimes perform `.commit()` inside the code<br>
(e.g. `task.execute()`) and therefore it's hard to predict which data<br>
are committed and which are not.<br>
<br>
In order to avoid this, we have to declare strict scopes for different<br>
layers. Yes, we definitely should base on idea that handlers should<br>
open transaction on the begin and close it on the end. But that won't<br>
solve all problems, because sometimes we should commit data before<br>
handler's end. For instance, commit some task before sending message<br>
to Astute. Such cases complicate the things.. and it would be cool if<br>
could avoid them by re-factoring our architecture. Perhaps, we could<br>
send tasks to Astute when the handler is done? What do you think?<br>
<br>
Thanks,<br>
igor<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, May 6, 2015 at 12:15 PM, Lukasz Oles <<a href="mailto:loles@mirantis.com">loles@mirantis.com</a>> wrote:<br>
> On Wed, May 6, 2015 at 10:51 AM, Alexander Kislitsky<br>
> <<a href="mailto:akislitsky@mirantis.com">akislitsky@mirantis.com</a>> wrote:<br>
>> Hi!<br>
>><br>
>> The refactoring of transactions management in Nailgun is critically required<br>
>> for scaling.<br>
>><br>
>> First of all I propose to wrap HTTP handlers by begin/commit/rollback<br>
>> decorator.<br>
>> After that we should introduce transactions wrapping decorator into Task<br>
>> execute/message calls.<br>
>> And the last one is the wrapping of receiver calls.<br>
>><br>
>> As result we should have begin/commit/rollback calls only in transactions<br>
>> decorator.<br>
><br>
> Big +1 for this. I always wondered why we don't have it.<br>
><br>
>><br>
><br>
>> Also I propose to separate working with DB objects into separate lair and<br>
>> use only high level Nailgun objects in the code and tests. This work was<br>
>> started long time ago, but not finished yet.<br>
>><br>
>> On Thu, Apr 30, 2015 at 12:36 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>> wrote:<br>
>>><br>
>>> Hi folks!<br>
>>><br>
>>> Recently I faced a pretty sad fact that in Nailgun there’s no common<br>
>>> approach to manage transactions. There are commits and flushes in random<br>
>>> places of the code and it used to work somehow just because it was all<br>
>>> synchronous.<br>
>>><br>
>>> However, after just a few of the subcomponents have been moved to<br>
>>> different processes, it all started producing races and deadlocks which are<br>
>>> really hard to resolve because there is absolutely no way to predict how a<br>
>>> specific transaction is managed but by analyzing the source code. That is<br>
>>> rather an ineffective and error-prone approach that has to be fixed before<br>
>>> it became uncontrollable.<br>
>>><br>
>>> Let’s arrange a discussions to design a document which will describe where<br>
>>> and how transactions are managed and refactor Nailgun according to it in<br>
>>> 7.0. Otherwise results may be sad.<br>
>>><br>
>>><br>
>>> - romcheg<br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Łukasz Oleś<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>