A connection string is configuration data, it has nothing to do in code, even less so in a
const. Pull it out of there, and into a proper configuration settings file. Also consider using Windows Authentication so that you don't need to have passwords stored in plain text anywhere.
What you've made thread-safe is the acquisition of the
Making the instance variable volatile can make it work, as would explicit memory barrier calls, although in the latter case even experts can't agree exactly which barriers are required. I tend to try to avoid situations where experts don't agree what's right and what's wrong!
A better implementation would use a
Lazy<T> instead of explicit locks and obscure keywords.
Now, a Singleton normally instantiates itself - so your field and
Instance would be a
Database object, not a
Database is a very unfortunate name for this concept BTW - your class has nothing to do with a database; if anything it's a
SqlConnectionProvider or whatever - but not a
The connection itself can be acquired by any number of threads. What's not clear is who is responsible for correctly disposing that connection.
IDisposable, and should be as short-lived as possible. Seems your intent is to reuse the same connection instance throughout the lifetime of your application, and have some cleanup/exit code deal with proper disposal (if at all?).
The whole idea doesn't feel right at all. The connection overhead is already taken care of with connection pooling, so there's no need to keep a single connection alive forever, even less so to use it across multiple threads.