IA104

[mP]

I would argue that anything that requires a Transaction context should accept it as a parameter or at the least take a provider which it can grab from when needed. Assuming that the tx is available by reading some magic global variable is wrong. Sure its a pain to pass tx ctx around etc but its just another parameter and shouldnt be treated as a magic global. Theres nothing wrong with setting up a tx before doing stuff that needs one and so on.

[Richard Vowles]

Its  just lazy even.

On Fri, Jul 26, 2013 at 4:54 PM, mP <miroslav...@gmail.com> wrote:

I would argue that anything that requires a Transaction context should accept it as a parameter or at the least take a provider which it can grab from when needed. Assuming that the tx is available by reading some magic global variable is wrong. Sure its a pain to pass tx ctx around etc but its just another parameter and shouldnt be treated as a magic global. Theres nothing wrong with setting up a tx before doing stuff that needs one and so on.

--
 
---
You received this message because you are subscribed to the Google Groups "illegalargument" group.
To unsubscribe from this group and stop receiving emails from it, send an email to illegalargume...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/illegalargument/7e8402b5-3a77-4c7f-a720-65cc51ab29d2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
---
Richard Vowles,
Grails, Groovy, Java, Javascript, AngularJS
Consistency is the last refuge of the unimaginative - Oscar Wilde
ph: +64275467747, google+:http://rvowl.es/UX8Bmq
podcast: http://www.illegalargument.com

[Matthew Farwell]

As someone who has spent days trying to find where the bloody hell a transaction is being created (with @Transactional) I can whole heartedly agree with this. If you have to explicitly pass a transaction context around, it rapidly becomes an obvious code smell if you're passing it to too many places. The way I found where the transaction was being created was to insert logging into the jdbc layer, I simply couldn't work it out from the annotations. Turns out there wasn't a transaction at the place where it was needed, but at pretty much every method below that. So one call to one web service caused ~1000 transactions.

And while we're on the subject, talking about @Autowired - we had one bean which had ~50 autowired dependencies. They didn't have any unit tests for this class surprisingly. Again, this would have been obvious if we'd had to use constructor injection. I find @Autowired really really useful, but on big systems it becomes really unwieldy.

Matthew Farwell.

2013/7/26 mP <miroslav...@gmail.com>

I would argue that anything that requires a Transaction context should accept it as a parameter or at the least take a provider which it can grab from when needed. Assuming that the tx is available by reading some magic global variable is wrong. Sure its a pain to pass tx ctx around etc but its just another parameter and shouldnt be treated as a magic global. Theres nothing wrong with setting up a tx before doing stuff that needs one and so on.

--

[mP]

50 ! isnt that smelly in itself ?