Connecting Tech Pros Worldwide Help | Site Map

Configuration parameter in SQL database

=?Utf-8?B?U3RlcGhhbmVWYXJpbg==?=
Guest
 
Posts: n/a
#1: Jun 27 '08
Hi all,

For some reasons, we've had to move away from the configuration files and
are now storing all the configuration parameters for our applications in a
SQL table. We have developped a library to manage the access to these
parameters and all our projects are now using this component. Our
applications vary can be web applications, web services, windows services,
even MS Office Addins.

Now here is the question that we are asking ourselves.

Shoud we or should we not keep the value of the parameters in static members?

Some developpers in the team would rather use dynamic members so that any
change to the underlying parameter in the table would be immediately
reflected without the need to restart the application pool in IIS or the
windows service.

Any comment or advice would be much appreciated to help us make our decision.

Cheers,

Stephane Varin
=?Utf-8?B?SmVmZiBXaW5u?=
Guest
 
Posts: n/a
#2: Jun 27 '08

re: Configuration parameter in SQL database


Well, we have the same basic concept here with one of our tables that stores
general configuration data across our applications as well.

If you're storing those values inside static members on the objects the only
way you're going to allow them to update when the database changes is by
reloading the appdomain they're hosted in. Typically this involves restarting
the application or service that is running unless you're managing the
appdomains yourself, which can get very complicated.

I would agree with the developers on your team that want to store the
configuration data dynamically. Your solutions will end up requiring less
maintenance, which in turn gives you time to work on other things. When the
data has to change (which it probably will) you won't need someone to go
around restarting everything.

Just my opinion, but I'd have to agree with your team.

"StephaneVarin" wrote:
Quote:
Hi all,
>
For some reasons, we've had to move away from the configuration files and
are now storing all the configuration parameters for our applications in a
SQL table. We have developped a library to manage the access to these
parameters and all our projects are now using this component. Our
applications vary can be web applications, web services, windows services,
even MS Office Addins.
>
Now here is the question that we are asking ourselves.
>
Shoud we or should we not keep the value of the parameters in static members?
>
Some developpers in the team would rather use dynamic members so that any
change to the underlying parameter in the table would be immediately
reflected without the need to restart the application pool in IIS or the
windows service.
>
Any comment or advice would be much appreciated to help us make our decision.
>
Cheers,
>
Stephane Varin
Marc Gravell
Guest
 
Posts: n/a
#3: Jun 27 '08

re: Configuration parameter in SQL database


There is a middle ground; you could cache the values with a moderate
duration - even a minute or two would save a *lot* of round-trips, while
negating the need to reset the app each time. There are various cache
layers that could do this for you; even the System.Web cache can be used
standalone (since 2.0; not in 1.1). Or kust keep an expiry DateTime.

Marc
=?Utf-8?B?U3RlcGhhbmVWYXJpbg==?=
Guest
 
Posts: n/a
#4: Jun 27 '08

re: Configuration parameter in SQL database


What about the overhead on our SQL server ?

The way I see it, our applications would be making tens of calls to this
database for each and every action, times the number of users...potentially
thousands of request to retrieve the same value over and over...

Do the benefits (avoiding the need to restart the application when a
parameter is changed) justify this culprit?

Configuration parameters are by essence fairly stable values, and the need
to change them usually arises when deploying a new version of the product,
which implies a restart anyway...

Well, I am very uncomfortable with this idea, I have to admit...

"Jeff Winn" wrote:
Quote:
Well, we have the same basic concept here with one of our tables that stores
general configuration data across our applications as well.
>
If you're storing those values inside static members on the objects the only
way you're going to allow them to update when the database changes is by
reloading the appdomain they're hosted in. Typically this involves restarting
the application or service that is running unless you're managing the
appdomains yourself, which can get very complicated.
>
I would agree with the developers on your team that want to store the
configuration data dynamically. Your solutions will end up requiring less
maintenance, which in turn gives you time to work on other things. When the
data has to change (which it probably will) you won't need someone to go
around restarting everything.
>
Just my opinion, but I'd have to agree with your team.
>
"StephaneVarin" wrote:
>
Quote:
Hi all,

For some reasons, we've had to move away from the configuration files and
are now storing all the configuration parameters for our applications in a
SQL table. We have developped a library to manage the access to these
parameters and all our projects are now using this component. Our
applications vary can be web applications, web services, windows services,
even MS Office Addins.

Now here is the question that we are asking ourselves.

Shoud we or should we not keep the value of the parameters in static members?

Some developpers in the team would rather use dynamic members so that any
change to the underlying parameter in the table would be immediately
reflected without the need to restart the application pool in IIS or the
windows service.

Any comment or advice would be much appreciated to help us make our decision.

Cheers,

Stephane Varin
Jialiang Ge [MSFT]
Guest
 
Posts: n/a
#5: Jun 27 '08

re: Configuration parameter in SQL database


Hello Stephane,

Thank you for the positive feedbacks of my initial reply.

The introduction of Caching in ASP.NET with the SqlCacheDependency Class is
the MSDN article:
http://msdn.microsoft.com/en-us/library/ms178604.aspx
It depicts the main features of ASP.NET SQL cache dependency, and tells the
different implementation of the mechanism in SQL server 2000 and 2005: SQL
server 2005 has the built-in support of Query Notification, whereas, SQL
server 2000 replies on polling which is less efficient.

To use the SQL Cache Dependency in the environment of ASP.NET 2.0 + SQL
Server 2005, please follow these two steps:

*Step 1. (SQL Server) Enable "Query Notification" in SQL server 2005*
http://msdn.microsoft.com/en-us/library/ms172133.aspx
with the SQL command:

ALTER DATABASE [DB Name] SET ENABLE_BROKER;

Note1: Before the run of this command, please make sure all the SQL
connections of the DB are disconnected. Otherwise, the command will hang.
Note2: Certain versions of SQL server 2005 don't include Notification
services:
http://technet.microsoft.com/en-us/l.../ms143500.aspx

*Step 2. (ASP.NET) Write code to use SqlCacheDependency*
http://msdn.microsoft.com/en-us/library/9dz445ks.aspx
This is a step-by-step demo of SqlCacheDependency in ASP.NET. If you are
interested in how to use it in Windows application, please refer to:
http://msdn.microsoft.com/en-us/library/a52dhwx7.aspx

A frequently used tip is to put the code:
SqlDependency.Start(GetConnectionString());
Into global.asax Application_Start function:

protected void Application_Start(object sender, EventArgs e)
{
SqlDependency.Start(GetConnectionString());
}

When you call this method, the runtime sets up the relationship between the
application domain and the connection string that will be used later during
the notification registration process.

For more reading of SQL Cache Dependency samples:
http://www.writebetterbits.com/2008/...2005-database_
11.html
This is a good demo of SQL Cache Dependency with LINQ

By the way, you may find some articles like these online:
http://www.codeproject.com/KB/aspnet...ASPNET_20.aspx
http://www.codeproject.com/KB/web-ca...endencies.aspx
They are about SQL Cache Dependency for SQL server 2000, which requires the
commands:
aspnet_regsql -ed -E -d School
aspnet_regsql -et -E -d School -t Users
These are not necessary in SQL server 2005.

Please let me know if you have any other concerns, or need anything else.

Regards,
Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================


sloan
Guest
 
Posts: n/a
#6: Jun 27 '08

re: Configuration parameter in SQL database


SOmething else to consider.

Greg Leake has created a "mini framework" about this configuration setting
up.

http://msdn.microsoft.com/en-us/netf.../bb499684.aspx


Focus on the configuration framework, and less on the WCF.

Basically, if you update a config setting (in the db), it pushes out all the
information.

Not sure if that's what you're after, but he did alot of work on it.




"StephaneVarin" <stephane@newsgroups.nospamwrote in message
news:0A46EA26-9E58-472C-B1E6-7F2E719BC687@microsoft.com...
Quote:
Hi all,
>
For some reasons, we've had to move away from the configuration files and
are now storing all the configuration parameters for our applications in a
SQL table. We have developped a library to manage the access to these
parameters and all our projects are now using this component. Our
applications vary can be web applications, web services, windows services,
even MS Office Addins.
>
Now here is the question that we are asking ourselves.
>
Shoud we or should we not keep the value of the parameters in static
members?
>
Some developpers in the team would rather use dynamic members so that any
change to the underlying parameter in the table would be immediately
reflected without the need to restart the application pool in IIS or the
windows service.
>
Any comment or advice would be much appreciated to help us make our
decision.
>
Cheers,
>
Stephane Varin

Jialiang Ge [MSFT]
Guest
 
Posts: n/a
#7: Jun 30 '08

re: Configuration parameter in SQL database


Hello Sloan and Stephane,

I agree that the "mini framework" in the .NET StockTrader Sample, i.e.
"Configuration Service", can be another consideration. As far as I know, the
source code of the configuration service is not published, so I cannot tell
its exact idea of the update callback. It might be using the similar
mechanism to SQL Cache Dependency. For more reading about the service,
please refer to the document:
http://download.microsoft.com/downlo...nicalGuide.pdf

Regards,
Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

"sloan" <sloan@ipass.netwrote in message
news:%23DgJT3G2IHA.5564@TK2MSFTNGP06.phx.gbl...
Quote:
SOmething else to consider.
>
Greg Leake has created a "mini framework" about this configuration setting
up.
>
http://msdn.microsoft.com/en-us/netf.../bb499684.aspx
>
>
Focus on the configuration framework, and less on the WCF.
>
Basically, if you update a config setting (in the db), it pushes out all
the information.
>
Not sure if that's what you're after, but he did alot of work on it.
>
>
>
>
"StephaneVarin" <stephane@newsgroups.nospamwrote in message
news:0A46EA26-9E58-472C-B1E6-7F2E719BC687@microsoft.com...
Quote:
>Hi all,
>>
>For some reasons, we've had to move away from the configuration files and
>are now storing all the configuration parameters for our applications in
>a
>SQL table. We have developped a library to manage the access to these
>parameters and all our projects are now using this component. Our
>applications vary can be web applications, web services, windows
>services,
>even MS Office Addins.
>>
>Now here is the question that we are asking ourselves.
>>
>Shoud we or should we not keep the value of the parameters in static
>members?
>>
>Some developpers in the team would rather use dynamic members so that any
>change to the underlying parameter in the table would be immediately
>reflected without the need to restart the application pool in IIS or the
>windows service.
>>
>Any comment or advice would be much appreciated to help us make our
>decision.
>>
>Cheers,
>>
>Stephane Varin
>
>

sloan
Guest
 
Posts: n/a
#8: Jul 3 '08

re: Configuration parameter in SQL database


Greg (Leake) has a new version out. It is more friendly then the first
version.
All code is available I believe.

At least that's what he said at TechEd2008.



"Jialiang Ge [MSFT]" <jialge@online.microsoft.comwrote in message
news:uvpt5Nm2IHA.6096@TK2MSFTNGP06.phx.gbl...
Quote:
Hello Sloan and Stephane,
>
I agree that the "mini framework" in the .NET StockTrader Sample, i.e.
"Configuration Service", can be another consideration. As far as I know,
the source code of the configuration service is not published, so I cannot
tell its exact idea of the update callback. It might be using the similar
mechanism to SQL Cache Dependency. For more reading about the service,
please refer to the document:
http://download.microsoft.com/downlo...nicalGuide.pdf
>
Regards,
Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
>
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.
>
This posting is provided "AS IS" with no warranties, and confers no
rights.
=================================================
>
"sloan" <sloan@ipass.netwrote in message
news:%23DgJT3G2IHA.5564@TK2MSFTNGP06.phx.gbl...
Quote:
>SOmething else to consider.
>>
>Greg Leake has created a "mini framework" about this configuration
>setting up.
>>
>http://msdn.microsoft.com/en-us/netf.../bb499684.aspx
>>
>>
>Focus on the configuration framework, and less on the WCF.
>>
>Basically, if you update a config setting (in the db), it pushes out all
>the information.
>>
>Not sure if that's what you're after, but he did alot of work on it.
>>
>>
>>
>>
>"StephaneVarin" <stephane@newsgroups.nospamwrote in message
>news:0A46EA26-9E58-472C-B1E6-7F2E719BC687@microsoft.com...
Quote:
>>Hi all,
>>>
>>For some reasons, we've had to move away from the configuration files
>>and
>>are now storing all the configuration parameters for our applications in
>>a
>>SQL table. We have developped a library to manage the access to these
>>parameters and all our projects are now using this component. Our
>>applications vary can be web applications, web services, windows
>>services,
>>even MS Office Addins.
>>>
>>Now here is the question that we are asking ourselves.
>>>
>>Shoud we or should we not keep the value of the parameters in static
>>members?
>>>
>>Some developpers in the team would rather use dynamic members so that
>>any
>>change to the underlying parameter in the table would be immediately
>>reflected without the need to restart the application pool in IIS or the
>>windows service.
>>>
>>Any comment or advice would be much appreciated to help us make our
>>decision.
>>>
>>Cheers,
>>>
>>Stephane Varin
>>
>>
>
>

Closed Thread