UPDATE: The following error was actually due to a simple bug which I missed. The only real message here that tired and stupid is a bad combination.
For reasons to do with some specific features of an ODBC driver we're forced to use, I've been trying to write a small application which directly uses ODBC calls. Since C# 2.0 is what I know most, I've been doing this using P/Invoke calls into ODBC32.dll.
The code I've written initially has been multithreaded. But I've noticed that as soon as I jump threads I'm getting AccessViolationExceptions. For instance, when I generate IntPtr references to an Environment and Connection in one thread and then try to use these in another thread in the generation of a Statement (SQLAllocStmt), it all goes pop.
I'm sure I can work around this, but is there some obvious reason for this? Is the unmanaged memory allocated by the calls into ODBC32.dll somehow bound to a particular thread?
This depends on:
The odbc driver: What is it?
Your code: Are you freeing the memory without realizing it?
Consider:
Whether you really need to do this. Can't you control the behaviour of the driver using the connection string, or using driver-specific commands through a command object?
If you do have to do this, can you isolate it into a single STA thread and use marshalling, or a task queue, to simplify your job?
If you do have to use it from multiple threads, can't you make sure each thread has it's own Connection and Environment?
Related
For part of a C# application I am executing some relatively simple networking commands. (ping, ipconfig, tracert, nslookup, etc.)
I have read this answer on when to use C# vs CMD/PowerShell in the general sense:
https://stackoverflow.com/a/4188135/8887398
However, I'm wondering particularly for networking, and the Systems.Net library, is there any major advantage in taking the time to write code to implement these in C# as opposed to creating a new command line Process() within a C# app and executing it that way? (The Process() route is really simple/easy to code within C# app)
Question: What are my main advantages of implementing networking commands with the C# Systems.Net library vs creating a new Process() within a C# app and proceed internally as if you were using the command line?
There is certainly nothing wrong with starting a process. You can even start PowerShell and use that for sequences of actions that are easy to do in PowerShell.
Starting a process is not as easy as you might think.
You need to read both standard output and error for example. Else, the process will hang randomly. Doing this is surprisingly hard.
Getting results from commands is harder compared to using a .NET class. In .NET you get objects and exceptions back. A process can only send you text and an error code.
There is also more overhead. Whether that matters depends on the frequency of such operations.
You could leave child processes orphaned. The best solution is using Windows Job Object to kill the child tree when the parent exits.
So it depends on the specific case. I would definitely do a ping from C# since that is very easy to do. Other commands might benefit more from starting a process.
I'm using c# driver for Cassandra with multi-threads processing.
At first, I tried to create a connection and execute command and then close the connection after done the work. But it's seem not to work for me, sometimes it's got an exception that No hosts available.
So, I changed to working with static connection. it's seem to work as well.
But when thread is working too fast, it's broken again. I've to put some Thread.Sleep for 1 second then it works.
And with this static solution, I tried to use Asynchronous process, BeginExecute and it's not work for me as well, exception No Hosts Available.
So, anyone has better ideas or better implementation on multi-threads processing working with Cassandra c# driver, it would be appreciate if you can share.
Thank you in advance.
Cheers,
Kin
CassandraSession can only have one connection at a time. It probably isn't thread safe now that I think about it. But the Connection Pool is thread safe, so if you use that you will always have a high availability connection
If you use asynchronous method,it looks like that:
Statement sta=new SimpleStatement("Select * from XXX where XXX;");
session.ExecutAsync(sta);
Make sure your setup is satisfying the connection requirements
The C# driver should definitely work in a multi-threading environment (1 cluster object, 1 session object/keyspace)
It's difficult to say why you are seeing the NoHostAvailable exception without seeing any code.
I'm looking for some feedback in regards to the best option for a problem I am working on.
To give you some background I recently inherited a broken business application (our project was using it, so we gained responsibility to fix it), I come from a SharePoint development background so a little C#, ASP.NET and SQL.
Currently we have an issue with the application where we continually receive timeout errors, I have narrowed it down to the web application calling a bunch of stored procedures to update status fields in other tables when something changes that might affect the status of other objects.
Without completely overhauling this application I have determined our best option is to offload these stored procedures to run in the background and not be tied to the UI. I've looked at a couple of options including:
Creating a separate thread to handle the execution. (Still times out)
Using BackgroundWorker (still times out, obviously it shouldn't but I can't seem to find out what is causing it to wait for the BackgroundWorker to finish)
Moving the Stored Proc execution to a job, which I then call from another SP. (This works, but the limitation is that I can only have one job running at once, and if multiple users update objects they then receive an exception because the job won't start)
Right now we have moved these stored procedures into a twice a day script, which updates all objects, however this is only a temporary fix.
I have two options that I'm looking at, and I'm hoping to get some guidance on the implementation of whatever you consider to be the best option:
Continue using the job and have the executing stored proc queue up items in a db which the job will loop through until empty. The executing stored proc will have to check if the job is running when it adds a new entry and then act accordingly.
It's been recommended that I look at using the Service Broker, but I am not familiar with it's use at all. I understand that it would likely be a better overall solution, as it allows me to queue up these updates in a more transactional way.
I think both these options are viable although I need some help in understanding the implementation of the second option. My other dilemma is with these stored procedures running anywhere from 45s to 20m how can I notify the user that changed the object that his/her updates have been made? This is where I fallback to using the job because i could simply add a user field into the 'queue' and have the stored proc send a quick email at the end.
Thoughts, suggestions? Maybe I'm over-thinking this?
If you are on .NET 4.5 and C# 5.0 use async and if you are on .NET 4.0 use TPL. They have the same underlying (almost) and async feature is built upon TPL (with some extra internals).
In any case TPL would be a proper choice.
Sounds like Service Broker would be an excellent solution to this problem. It's true that there is a bit of a learning curve to climb to get your head round how it works, but it's fundamentally pretty simple especially when your implementation is in a single database.
There's a good (and mercifully short) intro to how it works at http://msdn.microsoft.com/en-US/library/ms345108(v=SQL.90).aspx
Have a look at Asynchronous Procedure Execution. But I would look first if the updates can be improved, perhaps a simple index can eliminate the timeouts, and/or try to leverage snapshot isolation. These would be much simpler to try out w/o committing to 'major overhaul' of the application code.
I must also urge you to read Waits and Queues. This is a SQL Server methodology for identifying performance bottlenecks. Is a great way of narrowing down the problems of 'timeouts' to something more actionable (blocking, IO, indexes etc).
I know several topics on the subject have been discussed, because I have been reading a lot to try to resolve my issue, but somehow they happen to not fulfill my needs (maybe for the lack of detail). Anyway, if you think some specific 'topic' might be useful, please link it.
I'm developing a desktop application with WPF (and MVVM) and I'm using NHibernate. After researching about possible ways to manage my session, I have decided to use the session-per-form approach. By this way, I think I can fully use the features of NHibernate like lazy-loading, cache and so on.
As I'm working with a database, I don't want to freeze my UI while I'm loading or saving my entities, so I thought I should use a dedicated thread (in each form, which I think simplifies the development) to handle the database interaction. The problem, though, is how I should 'reuse' the thread (supposing I have a session associated with that thread) to make my 'database calls'.
I think I couldn't use TPL because I'm not guaranteed that the two tasks would run in the same thread (it's not even guaranteed that they will be run in different threads than the invoker)
I would prefer to use session-per-form, as I have seen similar discussions that end by using session-per-conversation or something like that. But anyway, if you find that session-per-conversation would be better, please tell me (and hopefully explain why)
Threads don't provide a way to directly run more than one method, so I think I would have to 'listen' for requests, but I'm still unsure if I really have to do this and how I would 'use' the session (and save it) only inside the thread.
EDIT:
Maybe I'm having this problem because I'm confusing thread-safety with something else.
When the NHibernate documentation says that ISession instances are not thread-safe, does it means that I will (or could) get into trouble if two threads attempt to use it at the same time, right? In my case, if I use TPL, different threads could use the same session, but I wouldn't perform more than one operation in the same session at the same time. So, would I get into trouble in that situation?
If I may make a suggestion, desktop applications are poorly suited to interact with the database directly. The communication is not encrypted and it's really easy for someone with even the slightest amount of know-how to grab the database password and begin messing with records using a SQL connection and corrupt your database.
It would be better to create a web service with authentication that stands between the desktop application and the database as you could create credentials for each person and every transaction would be forcibly subjected to your various business rules.
This would also take care of your threading issue as you would be able to create HTTP connections on another thread with little to no trouble concerning session management. A cookie value is likely all that would be required and RestSharp makes this fairly trivial.
Are there any templates/patterns/guides I can follow for designing a multithreaded server? I can't find anything terribly useful online through my google searches.
My program will start a thread to listen for connections using TcpListener.
Every client connection will be handled by it's own IClientHandler thread. The server will wrap the clientHandler.HandleClient in a delegate, call BeginInvoke, and then quit caring about it.
I also need to be able to cleanly shutdown the listening thread, which is something I'm not finding a lot of exampes of online.
I'm assuming some mix of lock/AutoResetEvents/threading magic combined with the async BeginAceptTcpClient and EndAcceptTcpClient will get me there, but when it comes to networking code, to me it's all been done. So I have to believe there's just some pattern out there I can follow and not get totally confused by the myriad multithreaded corner cases I can never seem to get perfect.
Thanks.
Oddly enough you may find something on a Computer Science Assignment, CSC 512 Programming Assignment 4: Multi-Threaded Server With Patterns. Altough it's C++ voodoo but the theory is quite understandable for someone who can do C#.
Acceptor/ Connector
Monitor Object
Thread Safe Interface
Wrapper Facade
Scoped Locking
Strategized Locking
Reactor
Half Sync/Half-Async
Leaders/Followers
Altough you can get the whole list of nice readings on the main page.
Take a look at this previous question:
How do you minimize the number of threads used in a tcp server application?
It's not strictly C# specific, but it has some good advice.