I think Option B is a good move.
On Wed, Oct 9, 2013 at 1:00 PM, Darren Shepherd wrote:
> This is blocking my spring-modularization branch as I coupled changing
> the DB transactions stuff with the spring stuff (maybe not the best
> idea...). So if everyone is on board with option 2, I'll look
This is blocking my spring-modularization branch as I coupled changing
the DB transactions stuff with the spring stuff (maybe not the best
idea...). So if everyone is on board with option 2, I'll look to get
it done by probably Tuesday. I'll create a branch from master,
independent of the spring
Pedro,
The @DB annotation adds a guard. It doesn't actually start or end a
transaction. It will check that the transaction should be rolled back
if one was started and not closed and that's about it. So the only
time transactions are really started is when you see txn.start() in
the code. So t
Darren,
Happy to hear your view on Spring.
+1 for option B
On Wed, Oct 9, 2013 at 8:06 PM, Kelven Yang wrote:
> +1
>
> Original Transaction class also has many tightly-coupled assumptions about
> the underlying data source, lock master. Developers are usually lost on
> when and where they sho
+1
Original Transaction class also has many tightly-coupled assumptions about
the underlying data source, lock master. Developers are usually lost on
when and where they should use @DB, for nested transactions, it does not
really work as expected.
Kelven
On 10/9/13 10:38 AM, "Chiradeep Vittal"
Darren,
I generally agree with you... just trying to point out what could be pitfalls
on the way to evolve the system.
On Oct 9, 2013, at 10:29 AM, Darren Shepherd wrote:
>
> I wish we were doing transaction per API, but I don't think that was
> ever a consideration. I do think the sync portion
+1 to option B (for a lot of the reasons enunciated by Darren).
Also, let's get this in right away so that by 1/31/2014 we are confident
about the change and fixed any bugs uncovered by the new scheme.
On 10/9/13 10:29 AM, "Darren Shepherd" wrote:
>Pedro,
>
>From a high level I think we'd probab
Pedro,
>From a high level I think we'd probably agree. Generally I feel an
IaaS platform is largely a metadata management framework that stores
the "desired" state of the infrastructure and then pro-actively tries
to reconcile the desired state with reality. So failures should be
recovered from
Darren,
My assumption when I tried to make sense of the transaction code is that the
underlying motivation is that the code is trying to create a transaction per
API call and then allow multiple modules to implement that API call...
i.e. the intent is do use a bit of what i would call a "web-serv
Some random responses.
Spring is good at two things. The core IoC container and TX mgmt.
The way I use Spring for IoC is I always ensure there is no dependency
on Spring itself. This means I don't really care too much about the
Spring core IoC container and would be open to using a different
con
f code easier.
> Future development should also be much better.
>
> Kind Regards,
>
>
> Sent from my Windows Phone
>
> From: Darren Shepherd<mailto:darren.s.sheph...@gmail.com>
> Sent: 10/9/2013 11:46 AM
> To: dev@cloudstack.apache
o: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Subject: [DISCUSS] Transaction Hell
Okay, please read this all, this is important... I want you all to
know that its personally important to me to attempt to get rid of ACS
custom stuff and introduce patterns, frameworks, libraries, etc
---Original Message-
> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> Sent: 09 October 2013 09:45
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Transaction Hell
>
> Okay, please read this all, this is important... I want you all to know that
> its
> personally i
Okay, please read this all, this is important... I want you all to
know that its personally important to me to attempt to get rid of ACS
custom stuff and introduce patterns, frameworks, libraries, etc that I
feel are more consistent with modern Java development and are
understood by a wider audien
14 matches
Mail list logo