Pitfalls of calling a static method from ASMX
I would like to know if there are any pitfalls when calling a static method from an ASP.NET web service.
internal static object SelectScalar(String commandText, DataBaseEnum dataBase)
{
SqlConnection sqlc = new SqlConnection(AuthDbConnection.GetDatabaseConnectionString());
object returnval=null;
if (sqlc!=null)
{
SqlCommand sqlcmd = sqlc.CreateCommand();
sqlcmd.CommandText = commandText;
sqlc.Open();
returnval = sqlcmd.ExecuteScalar();
}
return returnval;
}
So, for example, the above method is given; are there any problems with multiple web methods and multiple clients calling this method at the same time (say 1000 calls to a web method that calls this function)?
source to share
Since you are creating a new one SqlConnection
, you want to delete it or the connection will not be closed. See MSDN for usage.
The fact that its a static method though ... that doesn't seem to be a problem since you are not updating any shared state (globals).
EDIT: AFAIK, the "hooks" of static methods in web services are the same as in any other application. The only thing to remember is that a web service is a server that is expected to work reliably over a long period of time. Thus, things that can cause problems over time (memory leaks, db communication exhaustion, etc.) are more significant than for other applications that run for a much shorter period of time.
source to share
The thing to be aware of is when static members change state that is available to other threads in the application domain. In these cases, you must take proper steps to make this happen in an orderly manner.
Your method does not touch any state from itself (everything is local), so you are fine.
As duffymo and nader point out, you have to get rid of your connection as you have to dipost any object that implements IDisposable.
source to share
I don't know if C # is similar to Java, but opening an SQL connection and not being able to close it before leaving the method doesn't seem like a good idea to me. GC will clear it as soon as it goes out of scope, but this is not the same as closing a connection in Java.
An idiom in Java would require you to close the connection in a finally block. If you are not sure if a C # class does not require this, I would look at it.
You will soon find out - thousands of web calls will exhaust the number of available connections if they are few.
One more thing to check: Opening connections this way is expensive in Java, so they are usually concatenated. Is pooling also done in C #? Is it inefficient to open and close a database connection? Could you do the same with static sharing? If you go that way, there might be input issues coming into play.
source to share