Huge +1. I actually have some knowledge about how transactions work in
Nailgun, and the saddest is that the worst parts are Network Managers and
garbage code in various task helpers. Please add me to discussions on
topic, I'm back from vacation on Thursday.
18 Май 2015 г. 18:17 пользователь "Alexan
Let's collect work items together:
1. Introduce UnitOfWork for generated astute messages. All messages
should be sent to Astute only after HTTP handler is finished. For example
in ApplyChangesTaskManager we are casting messages during processing method
'_execute_async_content'
2. Al
> We don't need transactions, for example, in GET methods.
It doesn't matter whether want we or not. The SQLAlchemy implicitly
starts transaction on first "select" query and it's ok. I mean,
perhaps it's not ok, but definitely it won't lead to great performance
degradation. A large number of proje
I mean, that we should have explicitly wrapped http handlers. For example:
@transaction
def PUT(...):
...
We don't need transactions, for example, in GET methods.
I propose to rid of complex data flows in our code. Code with 'commit' call
inside the the method should be split into independent
> First of all I propose to wrap HTTP handlers by begin/commit/rollback
I don't know what you are talking about, but we do wrap handlers in
transaction for a long time. Here's the code
https://github.com/stackforge/fuel-web/blob/2de3806128f398d192d7e31f4ca3af571afeb0b2/nailgun/nailgun/api/v1/handl
On Wed, May 6, 2015 at 10:51 AM, Alexander Kislitsky
wrote:
> Hi!
>
> The refactoring of transactions management in Nailgun is critically required
> for scaling.
>
> First of all I propose to wrap HTTP handlers by begin/commit/rollback
> decorator.
> After that we should introduce transactions wra
Hi!
The refactoring of transactions management in Nailgun is critically
required for scaling.
First of all I propose to wrap HTTP handlers by begin/commit/rollback
decorator.
After that we should introduce transactions wrapping decorator into Task
execute/message calls.
And the last one is the wr
Hi folks!
Recently I faced a pretty sad fact that in Nailgun there’s no common approach
to manage transactions. There are commits and flushes in random places of the
code and it used to work somehow just because it was all synchronous.
However, after just a few of the subcomponents have been mo
