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
Darren,
Thank you for the great investigative work. As for the assert, I think
that if no one else at least Jenkins should run with asserts on, so we
can see if a commit breaks something.
As for the framework, I think your proposed solution sound good. I am
not a big fan of spring. It does some t
Hi Darren,
Greetings from Nairobi.
First, let me start by saying that you for the email .
I personally think the options were explained very well.
Now on a serious note, I think that it would be good practice to ensure that we
go with a standardized method of doing things.
I therefore support th
Hi Darren,
Thank you for explain this issue in huge detail.
Could I respond with some questions?
1. If @DB declarations are not detected, because Java 'assert' is not turned
on, can we use a different mechanism to check for @DB?
2. What standard framework do you recommend using for DB transact
13 matches
Mail list logo
