C#
|
|
 |
|
there is appear in server explorer the database ozeki.mdf which i have created in my application, but i couldn't make the correct connection to it ,,, i copy the connection string from ozeki.mdf property which contain the full path but it result the above error ,,,
|
|
|
|
|
Is it asp.net, desktop or metro application?
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
hi,
I dig around [^]understand that depending on compiler architecture using statement is actually a syntactic sugar ...
Translate FROM:
using (TransactionScope scope = new TransactionScope())
{
...
}
TO:
TransactionScope scope = new TransactionScope();
#PT1#
try {
...
#PT2#
scope.Complete();
#PT3#
} finally {
if (scope!= null)
((IDisposable)scope).Dispose();
}
Previously, as I read, depending on compiler architecture code may blow up at #PT1# and thus finally cleanup block would never execute. But again, I read further that Microsoft already fixed this problem.
What I want to ask is, is using(TransactionScope) now Thread.Abort safe? If code blows up at #PT2# and not #PT3#, would "scope.Dispose" rollback the transaction as well?
Thanks
dev
|
|
|
|
|
At PT1 you haven't actually done anything with the scope, so even if it doesn't get cleaned up immediately, you haven't done anything which could damage your database.
What happens if it dies at PT2 is dependent on TransactionScope.Dispose, but I'd assume it does the right thing.
Thread.Abort is a blunt instrument, though, so it should only be used in extreme cases.
|
|
|
|
|
devvvy wrote: What I want to ask is, is using(TransactionScope) now Thread.Abort safe?
Not as far as I know (cannot test now), and shouldn't be. Terminating is exactly that - terminating. No cleanup, nothing gracefull, but an exit.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
No, you can't guarantee that the Dispose method will be reached with Thread.Abort - this applies to pretty much any disposable class wrapped with using, and is not specific to TransactionScope. To understand why this is the case, it's important to understand that Thread.Abort is triggered as an asynchronous exception (unlike most other exceptions which are synchronous). This means that there is no guarantee as to when the exception is raised.
As you've pointed out, the using pattern is effectively syntactic sugar for try/finally, and I'm a really big fan of it. Thread.Abort, however, tramples over this sandbox because of a nasty little timing issue. If your code is lucky enough to abort during the bit in the body of the using statement, then the finally part, and that's a fine thing. If, however, your code has just to say entered the finally portion and the abort exception is raised, the code will drop out of the finally block at the point that it encounters the exception - even if it hasn't called Dispose yet.
However, apart from forcing termination of the program, I have never seen a system that really needs a Thread.Abort as there are generally other, safer methods to cancel a thread. Use of Thread.Abort is generally recommended by people who aren't aware that there are issues with using it, as it is an easy method to implement.
modified 18 Feb '13 - 12:24.
|
|
|
|
|
Pete O'Hanlon wrote: If, however, your code has just to say entered the finally portion and the abort exception is raised, the code will drop out of the finally block at the point that it encounters the exception
Thanks very much Peter!
dev
|
|
|
|
|
Don't mention it. I'm glad to help, and this is the type of esoteric "how does it really work" question that I enjoy answering.
|
|
|
|
|
having the bomb dropped during entry to Finally block was something that I never seen in other articles (many of which full of half answers), do I am actually quite delighted that I can finally put this question to rest.
dev
|
|
|
|
|
Pete O'Hanlon wrote: I have never seen a system that really needs a Thread.Abort
Curious about that.
A windows service that is supposed to 'stop' will have difficultly actually doing that if normal threads continue to run. So something which doesn't have control over a child thread and which has already attempted to nicely stop the thread can use Abort to force the issue.
Is there an alternative?
|
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin
Submit an article or tip
Post your Blog
