views:

48

answers:

2

Hello all,

This is probably a simple one...

Right now I have a working web service (programmed in c#) and it offers up two webmethods that either read or write data to a MS SQL database. What I want to know is this... Do I have to worry about errors when multiple users try to connect to, reading from, and writing to the database? Furthermore, should I be using threads and locks in my webmethods when they access the database (right now, I'm not using threads or locks)?

Here is some idea of what I have running now (code snippet):

[WebMethod(Description = "Attempts to post a new score to the scoreboard.")]
    [ScriptMethod(ResponseFormat = ResponseFormat.Json)]
    public TextMessage UpdateScoreboard(string password, string playerName, 
          int level, int gameBoard, string auth)
    {
        SqlDataReader myReader = null;
        SqlCommand myCommand = null;
        SqlConnection myConnection = null;

        /*
        The method then attempts to connect to the DB, 
        look for a duplicate playerName, and if there isn't one,
        data is entered into the DB ... using the INSERT command.
        */
    }

Thanks.

+1  A: 

Yes, you have to worry about it. (But not with threads and locks in your webservice - that probably won't help).

I think you can handle a certain amount in the stored proc (locking hints, try/catch exception handling) if you use that through SqlCommand. You still might become have errors so you'll also have to handle them in the web service itself, too.

Cade Roux
Hello, thanks for responding. Could you be more specific as to the type of "locking hints, try/catch exception handling" you're referring to? Thanks.
borg17of20
You need to understand locking - this happens at the database-level regardless of the clients attached: http://msdn.microsoft.com/en-us/library/aa213039(SQL.80).aspx TRY/CATCH is an error handling technique supported in T-SQL: http://msdn.microsoft.com/en-us/library/ms175976.aspx
Cade Roux
Thanks for the response. Most of my experience with databases has been with SQLite, so I understand the need to factor in locking, but I was hoping MS SQL was a bit more sophisticated and just handled all that automatically (especially considering it's a web-targeted technology). What you've posted is helpful. I hadn't considered using try/catch blocks in the SQL itself. At present, I'm only using them in the c# code. Thank you, and I'll take this all under advisement.
borg17of20
@borg17of20 SQL Server does handle locking itself. You can run in the default locking behavior without encountering a problem. SQL Server will NEVER allow the database to be in an inconsistent state. What can always happen with any RDBMS is that you can get in a deadlock situation or a temporary blocking situation while one process waits to acquire a lock. But it's a multi-user database. If you have hundreds or thousands of users hitting the database and you want to keep performance snappy, you have to understand how to reduce the footprint of your transactions to avoid lock escalations.
Cade Roux
+1  A: 

You don't have to worry about it heavily depending on the situation. As is the nature of databases, you might have situations were folks reading from the database are getting 'old' information, as in they might not get information that was entered recently from when the read operation took place. If this is a big issue for your specific situation then you'll have to think about using locks, however if that isn't a big deal you should be fine.

However, if you start getting a heavy volume of requests either to write or read, you may have to worry about locking or concurrency issues. Based on the simplicity it doesn't really sound like you have to worry much about it though.

Regardless, make sure you handle exceptions and plan for the obvious things that could happen (connection to SQL is down, various error conditions that may be present in your code, etc.)

I generally recommend against locking and threading unless you absolutely have a good reason to go down those paths. Threading should also be far less of an issue here due to the nature of web services, they are designed to handle concurrent usage. That is unless you have a very long running service request, then I'd move that into a thread, but, the less complexity the better.

Capital G
Thanks for responding. I'm not worried about users getting "old" data... they can refresh their interface if needed. I am just worried about errors. That said, all the relevant read/write requests are already surrounded with try/catch syntax. So, if I understand your response correctly, the only thing I might need to worry about is when there's a heavy load and someone's request might get blocked due to built-in locking etc.? If so, that's fine. The error message will be passed onto the use and he/she can just resubmit. BTW, these commands are simple INSERT/UPDATE commands anyways. Thanks.
borg17of20
If you have a heavy load, your service might stop accepting requests, there are a multitude of settings you can configure for your web service to handle requests and payload sizes as well as security issues.I would recommend that when handling errors and returning the error messages, that you think about security, is it okay to give raw error messages to your users or is it smarter to send them generic messages to keep the details of your code hidden? Standard security practice is all but I wanted to mention it.
Capital G
Ok. Thanks for the help. Right now the load is extremely low (no more than 5 users at time), but I was trying to plan ahead. Also, thanks for the advice about security. Right now all I return is a generic error message (regardless of the actual error type), so I think I'm set there. Lastly, you mentioned settings to change for handling requests and payload sizes... can you point me to a good website with that info, or maybe some help coming up with a decent search string for Google? I'm kind of new to web services. Thanks.
borg17of20
I'm no expert on web services either, but if your using WCF you might reference, I think your not using WCF however because you are using WebMethods, so you will have less control over those kinds of things. Your probably alright for what your doing is this a serious project or just hobbyist/learning?Either way, I'd recommend taking a look at WCF services as they come with a lot more features and you can configure things as necessary. It could be overkill though, something to think about at least.http://msdn.microsoft.com/en-us/library/ms733932.aspx
Capital G
At present, I'm not using WCF, but the website you linked to was a good read and it's something I'll definitely use if I need to in the future. Right now, this is just a simple scoreboard web service for an Android game I've released. The data transfers and the number of users are small, but I figured I'd ask this question just in case it becomes popular or I decide to implement the same basic thing in larger projects. Thanks again.
borg17of20