cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: [DISCUSS] Transaction Hell
Date Wed, 09 Oct 2013 15:19:04 GMT
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
container, but just for practical reasons its safer to stick with
Spring because of the huge user base and excellent quality.

Even if you don't use Spring IoC, you can still use Spring TX.  I have
never found a better TX mgmt framework than Spring.  It is extremely
comprehensive.  So if your not using container managed transactions
(JEE and EJB nonsense), then I really think Spring TX is the only

Spring MVC, Spring Batch, Spring WS, Spring [Whatever], are mostly
nonsense in my mind and I don't care to use them.  I don't subscribe
to the whole Spring world.  Just IoC (because IoC truly revolutionized
Java) and TX.

Regarding asserts.  I don't care for Java asserts.  Computers are fast
and extra null checks here and there are fine to just have in the
code.  It is not like we are writing a stock trading platform.  I
would prefer we never use asserts.  I hate to find bugs that only
happen when asserts are on or off.  If your not aware, Java asserts
are turned on with a runtime option "-ea."  They aren't a build time
thing like you see in C macro based ASSERTS.

Regarding what standard framework we should use.  At the end of the
day I'm trying to move towards Spring TX.  The best way to use Spring
TX is to use declarative transaction management.  The existing ACS
code base uses a lot of programmatic tx mgmt.  Well, in reality its
100% programmatic.  What I mean by programmatic is that in the code
you do tx.start(), tx.commit().  With declarative tx mgmt you use AOP
to isolate portions of code (like dao methods) to
start/commit/rollback the TX.  I don't think we will move away from
programmatic tx mgmt anytime soon, so if we move to Spring I don't
want us to suddenly start using Spring APIs everywhere.  Instead I
will propose we stay with a light wrapper, which will be the API I
already proposed in Option B.  It won't be 100% Spring, as we still
have a custom light wrapper, but at least at that point, anybody who
knows spring TX (or reads the docs) will understand what is going on.
Also protects us in the future if some hot new framework comes along
we should ideally be able to switch to it.

(Random thing, I've noticed in the code instances where the code is
doing txn.start() and then multiple txn.commit().  The transaction
framework AFAIK wasn't built for this.  The first commit will commit
or not depending on if the tx was nested.  The second commit will
either not commit or will destroy the internal state stack of the
transaction class as it will commit the parent tx.  So, for example, I
don't think AlertDaoImpl.archiveAlert() does at all what the
programmer who wrote it thought.  It's stuff like this that makes me
think we just need to bite the bullet, do the hard work, and clean
this up.)


View raw message