By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,760 Members | 955 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,760 IT Pros & Developers. It's quick & easy.

Configuration parameter in SQL database

P: n/a
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
Jun 27 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
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:
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
Jun 27 '08 #2

P: n/a
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
Jun 27 '08 #3

P: n/a
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:
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:
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
Jun 27 '08 #4

P: n/a
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 (ji****@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:
ms****@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Jun 27 '08 #5

P: n/a
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" <st******@newsgroups.nospamwrote in message
news:0A**********************************@microsof t.com...
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

Jun 27 '08 #6

P: n/a
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 (ji****@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:
ms****@microsoft.com.

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

"sloan" <sl***@ipass.netwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
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" <st******@newsgroups.nospamwrote in message
news:0A**********************************@microsof t.com...
>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


Jun 30 '08 #7

P: n/a
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]" <ji****@online.microsoft.comwrote in message
news:uv**************@TK2MSFTNGP06.phx.gbl...
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 (ji****@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:
ms****@microsoft.com.

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

"sloan" <sl***@ipass.netwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
>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" <st******@newsgroups.nospamwrote in message
news:0A**********************************@microso ft.com...
>>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



Jul 3 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.