[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 important to me to attempt to get rid of ACS custom stuff and
introduce patterns
@cloudstack.apache.orgmailto: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 that I
feel
development should also be much better.
Kind Regards,
Sent from my Windows Phone
From: Darren Shepherdmailto:darren.s.sheph...@gmail.com
Sent: 10/9/2013 11:46 AM
To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org
Subject: [DISCUSS] Transaction Hell
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
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
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
+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 darren.s.sheph...@gmail.com wrote:
Pedro,
From a high
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
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,
Happy to hear your view on Spring.
+1 for option B
On Wed, Oct 9, 2013 at 8:06 PM, Kelven Yang kelven.y...@citrix.com wrote:
+1
Original Transaction class also has many tightly-coupled assumptions about
the underlying data source, lock master. Developers are usually lost on
when
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
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
I think Option B is a good move.
On Wed, Oct 9, 2013 at 1:00 PM, Darren Shepherd darren.s.sheph...@gmail.com
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
13 matches
Mail list logo
