|
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:
<br />
using (TransactionScope scope = new TransactionScope())<br />
{<br />
...<br />
}<br />
TO:
<br />
TransactionScope scope = new TransactionScope();<br />
#PT1#<br />
try {<br />
...<br />
#PT2#<br />
scope.Complete();<br />
#PT3#<br />
} finally {<br />
if (scope!= null)<br />
((IDisposable)scope).Dispose();<br />
}<br />
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:24pm.
|
|
|
|
|
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?
|
|
|
|
|
It's down to the way you write your threading code. I tend to make a lot of use of Monitors to help with threading - the beauty of a Monitor is that you can pulse all of the monitor objects simultaneously, and let your thread code just check a simple volatile bool to determine whether or not the thread should stop at that point.
|
|
|
|
|
Pete O'Hanlon wrote: ...just check a simple volatile bool to determine whether or not the thread should
stop at that point.
Yes. That works well if you wrote the code. Or had a chance to review it at least.
If you didn't write the code, or made a mistake then the thread will continue to run.
And the service will also continue to run because until that thread stops the service will not stop. And the only recourse without Abort() is to use task manager to kill it.
|
|
|
|
|
I thought we were talking about if we'd written the code here. All of a sudden, this has taken a turn into someone else's code.
|
|
|
|
|
Pete O'Hanlon wrote: I thought we were talking about if we'd written the code here.
It was the solution I used at the time, so I was wondering if another solution existed.
I also spent quite a bit of time figuring out exactly what happens when a windows service 'exits' as well. Which is why I came to the conclusion that one must explicitly call Environment.Exit() in a service Stop() method (after attempting to nicely stop all the threads.)
|
|
|
|
|
hi.. i have dot NET framework software installed on my computer which includes microsoft SQL sever 2008. Do I have to install MS SQL server software again so as to be able to connect or retrieve data from the database? plz help.
|
|
|
|
|
No you don't need to install anything else, you can connect via code.
What is lacking is the management studio as you only get the express edition with no GUI. This makes setting up/ managing DBs hard-ishbut not impossible as you can always create SQL and execute via a console app or similar. You can download an express (free) version of management studio here[^] to provide a GUI, I don't know how good it is as we've got the full thing at work. I dare say it'll get the basics done.
|
|
|
|
|
THANKS AM GRATEFUL FOR ALL YOUR RESPONSES.
|
|
|
|
|
hello,,
i am not so sure but as i know 2010 and 2012 contain its inbuilt sql server,,,so you don't need to istall again external sql server...you can connect to the databse using code.
modified 18-Feb-13 10:16am.
|
|
|
|
|
They don't contain "inbuilt" SQL servers. They install either SQL Server 2008 Express or 2012 Express with LocalDb, depending on which version of Visual Studio and edition you install.
|
|
|
|
|
We are developing a daily planing system, the system will work like a calender planer with multi clients and servers...
The questions is which c# middleware should we use for this kind of 'distributed system'????
This is a picture of the systems architecture
Uploaded with ImageShack.us
modified 18-Feb-13 6:09am.
|
|
|
|
|
dude - I'd edit this and fix the link - it doesnt go where you think it should !
'g'
|
|
|
|
|
It works now 
|
|
|
|
|
ok .. well, as devvvy says, whats wrong with ASP.NET ? (its one option, certainly less complex than using a message bus)
In this case, tier 1 - Client uses a browser, tier 2 is an ASP.NET app, tier 3 is the data-base
Does it need to be more complicated, or is there some other thought process you're having ?
'g'
|
|
|
|
|
by middleware i presumed you mean some sort of message bus but why you need a message bus for a calendaring app? it's asp.net is it not?
dev
|
|
|
|
|
Because my teacher requires using middleware, the course is about distributed systems and he wants us to use middleware in this system
|
|
|
|
|
but has your teacher given you a definition of 'middleware' ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
