Tell me how wrong and stupid I am about T-SQL transactions
-
Why the fuck don't you just fix the SQL? This seems like ridiculous over engineering to me. Don't let your SQL get out of control like this.
-
Any proposals here are going to require changing some amount of code. Adding a couple checks on @@trancount to methods isn't very different from adding a transaction stack to them.
Ok.
-
You can see how large the code is above. It ain't large.
-
Checking @@trancount inside the CustomTransaction class is going to double or triple our back-and-forths to the database. That's a lot of additional network traffic to get something I could just get from within the class itself (like I am doing now.)
Why the fuck don't you just fix the SQL?
I don't have the time or inclination to rewrite the app. For the fucking 539th time.
Guys. Look. I know we're in an industry full of magic and fantasy, and I know everybody wants to just rewrite everything from scratch all the time forever. Well, I don't. I'm this thing called a "pragmatist"-- you may recognize that word, it's used to describe people in IT who actually get fucking work done instead of just dicking around with 3 new technologies every week.
The goal here is to reduce bugs and potential bugs. That is the goal. Keep your eyes focused on that goal. You see it? Good. Now here's a little trivia question for you:
How does rewriting a significant portion of the application contribute to that goal?
I'll give you a few seconds to come up with an answer...
https://www.youtube.com/watch?v=73tGe3JE5IU
Bzzt! Time's up. What was your answer? "It doesn't contribute to that goal at all, in fact it has the potential of creating thousands of new bugs?" Correct!
-
-
I don't have the time or inclination to rewrite the app. For the fucking 539th time.
Then what the fuck are you getting paid for? To not rewrite the app? To just put a bandaid on a pile of shit? To do exactly what? Just make it work no matter how WTF?
-
Then what the fuck are you getting paid for?
Back-end C# development.
To not rewrite the app?
Uh yeah? Why, is that unusual in some way? Do you think Adobe hires Photoshop developers for the sole intention of having them rewrite the app from scratch?
To just put a bandaid on a pile of shit?
If that's how you want to think of it, knock yourself out. Just an FYI, though, pretty much every software product you use on a daily basis (and definitely all the successful software out there) is a pile of shit covered in bandages. Welcome to reality. I hope you enjoy your stay.
To do exactly what? Just make it work no matter how WTF?
Well I think not touching 75,000 lines of debugged and working code, creating uncountable new bugs, just become some moron on the Internets thinks our data access layer is sub-par is pretty low on my priority list.
-
Holy shit, I just got you to agree with @atwood.
Irony is priceless.
-
Consider yourself trolled, troll.
-
Look, don't nest transactions. Just don't do it. Outer transactions don't know what's happening with inner transactions, and then you can open up multiple connections to the database when you do that shit.
You can have a situation where one query opens multiple connections to a DB or a table and the same single query then puts locks on the table. You can lock your own query out of itself when you nest transactions. Just don't do it.
There are almost always better ways to do things with a database than this.
-
We're not sure if it actually does this or not,
why not start there? repro on local an interleaved transaction exception so you know what happens. then capture it in prd, log a backtrace and rethrow.
If the issue is not happening you really don't need to build any complex internal infrastructure to detect it.
-
why not start there? repro on local an interleaved transaction exception so you know what happens. then capture it in prd, log a backtrace and rethrow.
Sigh.
This thread is going to just turn into me repeating myself over and over isn't it?
I have no way of testing every execution path of the app.
In any case, this isn't even my idea, remember? I'm taking code written by my boss that attempts to detect DB bugs and fixing it so it doesn't throw thousands of false positives.
-
This thread is going to just turn into me repeating myself over and over isn't it?
I have no way of testing every execution path of the app.
In any case, this isn't even my idea, remember? I'm taking code written by my boss that attempts to detect DB bugs and fixing it so it doesn't throw thousands of false positives.
You need something that can detect whether there's a transaction currently active; if so, you can piggy back on it, and otherwise, you make a new one. If you were using Java EE (I know, it's nasty) then I'd say that you'd be looking for the
TX_REQUIREDattribute on the methods. I don't know what the equivalents in the .NET ecosystem are.AOP does help with transaction management. It's normally a bit of a pain in the ass, but it's as nothing compared with having to put the correct transaction handling crap into hundreds of methods (because the simple
usingresource cleanup doesn't cover it; an exception flowing past a transaction boundary should trigger rollback under normal sanity levels). AOP lets you wrap things up with minimal effort and keep some hair on your head for pulling out later…
-
What is AOP?
-
It's what a Yorkshireman says to greet a friend
-
(because the simple
usingresource cleanup doesn't cover it; an exception flowing past a transaction boundary should trigger rollback under normal sanity levels).The cleanup method (whatever C# calls it) should just rollback, and then you can have an explicit commit call (or call to a wrapper of commit) in your code -- that's what I've done with the transaction stuff I did in C++, and it works a treat ;)
The other way to do this is to make the cleanup method sensitive to whether unwinding is taking place, but that's only guaranteed-reliable if all error handling flows through the EH mechanism, which I wasn't able to guarantee in my application.
-
The other way to do this is to make the cleanup method sensitive to whether unwinding is taking place, but that's only guaranteed-reliable if all error handling flows through the EH mechanism, which I wasn't able to guarantee in my application.
That's why it's better to do this sort of thing via AOP in Java or C#; those guarantees can be made there.
-
The cleanup method (whatever C# calls it)
[s]Destructor.[/s]Actually, that's a bad idea; the class should implement
IDisposable, and clean up inDispose().
-
I was just correcting you when I saw your edit. Hanzo denied!
(the conversation was specifically talking about
using, so Dispose is absolutely correct)
-
-
I'll make my own ACL! With hookers and blackjack
-
What is AOP?
AOP is Aspect Oriented Programming. It will never be properly supported in .Net because Anders Hejlsberg has bluntly answered "No" when asked if he will ever support it.
-
It will never be properly supported in .Net because Anders Hejlsberg has bluntly answered "No" when asked if he will ever support it.
A compile-time rewrite would be quite enough, though load-time weaving is pretty awesome.
-
Actually, that's a bad idea; the class should implement
IDisposable, and clean up inDispose().Disposer?
That's why it's better to do this sort of thing via AOP in Java or C#; those guarantees can be made there.
I don't really see why AOP's worth the hazards for this -- some sort of manual decoration that says "this block takes place as a transaction" is much clearer to the next guy who has to read your code, especially if you only need transactions in some places.Can you tell in a C# disposer whether there is exception unwinding going on?
-
After reading up on it, I say good. Looks like tons of effort/confusion for very little benefit.
-
Looks like tons of effort/confusion for very little benefit.
Or to quote the Python philosophy (PEP 20): "Explicit is better than implicit" -- and AOP is all about implicit.
-
I don't really see why AOP's worth the hazards for this -- some sort of manual decoration that says "this block takes place as a transaction" is much clearer to the next guy who has to read your code, especially if you only need transactions in some places.
I prefer to anchor my pointcuts to annotations anyway, so that's still explicit. Just declarative explicit.
-
After reading up on it, I say good. Looks like tons of effort/confusion for very little benefit.
That's my opinion too. Debugging an application that make heavy use of AOP sounds like a nightmare.
-
-
I prefer to anchor my pointcuts to annotations anyway, so that's still explicit. Just declarative explicit.
Decorators, anyone?
"Except when marking the ends of blocks."
Eh, indentation's no less explicit than any other way of marking the end of the block.
-
Eh, indentation's no less explicit than any other way of marking the end of the block.
I don't think you can get more explicit than having a dedicated token for it, and that's something that the python lexer adds anyway...
-
Eh, indentation's no less explicit than any other way of marking the end of the block.
Actually, it's lots less explicit. It's a missing something instead of an explicit something.
-
It's what a Yorkshireman says to greet a friend
-
It's what a Yorkshireman says to greet a friend
(That might only be funny if you know Swedish pronunciation…)
