I absolutely and gladly agree with you – if everybody’s needs can be met with a single version then… hooray! I was simply anticipating the standard objection to “non-DB” data storage – web farm compatibility. Microsoft would like us all to believe that SQL Server is the only solution for web farming! I agree that an alternative way could be found, and that this way could be “redundant but harmless” in a single-server setup. One of my primary motivations here is to stimulate discussion of XML as the possible “format” for settings – as you will know, “SQL-thinkers” sometimes cannot “see” the value of XML-based solutions (and vice-versa). It’s like two different and philosophically incompatible religions ;-)
Another neat trick with .NET caching is to make one cache entry dependent on another. Thus a nominated “control” entry in the cache (itself tied to an external dependency) could cause a “domino” update throughout numerous cache entries. Furthermore, there is an event-raising mechanism in there which, via remoting, could be the key to propagating farm-wide updates.
IMHO we should, from this point on, separate our thinking into “settings data” and “content data” – whilst they may well use the same mechanisms in particular setups, we should allow them to diverge: each “content handler” (module) should be able to address a data store of its own nomination.
And whilst I’m in the pulpit, let me point out that Microsoft produces two database products that are of far higher performance potential than SQL Server and no less sophisticated in their own ways. The first is the humble File System (furiously fast and automatically cached by IIS). The other is, broadly, XML (specifically: an “in-memory database” utilizing XPath queries).
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Cory Isakson
To: Jeremy Esland; 'Geert Audenaert'; email@example.com
Subject: RE: [Rainbowportal-devel] multi-database setup proposal
The desire to maintain “web farm” capability in Rainbow complicates the issue further L: we should make a decision early in the game as to how this will be supported. It is always possible that we produce two versions of Rainbow – single server and multi-server – as a way of avoiding unnecessary complexity for the majority of Rainbow installations (which one presumes will be of the single server type). I could be wrong (please tell me), but I think this would only require two versions of the “Data Access Layer” – everything else would be common?
I am one of the people the requires web farms support. I do not think there are that many areas where the farm is treated differently. It really comes down to using central data stores instead of local ones. XML files for settings is great, but for farms a way to approach it is to store the settings in a central DB, then generate the XML files for each server as necessary. Some kind of dirty bit approach could tell Rainbow it needs to refresh the local file. As long as the settings and content both use a pluggable DAL then there should not be a problem, but even on the farms I like to optimize as much as possible. This will give speed to the product, but also allow for maitaining the central repositiory for everything. The other big issue has to do with caching. Caching on farms can be difficult when data is changing, but displaying data is not a problem once the cache is refreshed. I have seen some articles for refreshing the cache in a farm setup. Like the settings mentioned above, if the data is in a DB and then some kind of local XML file can be used to tell the cache that it needs to refresh then that might work great. .NET Caching supports an XML file depnedancy and can be configured to cause a refresh when the XML file is updated. I do not think it will be hard to come up with a data model that works optimally for farm and non-farm configurations. As one of the primary people concerned with farm support I will be happy to help on that aspect and work on a plan for supporting farms without complicating everyone elses life. I am thinking that a single server that uses XML files as the datastore could still use the techniques I have mentioned even though they might not be necessary, they would not hurt anyting. Another thought might be to make all of the caching and settings items work differently for central DB systems (SQL, mySQL, Oracle, Web Services, etc), meaning they would do the extra work for local caching and local settings. If a local DB (Access, XML, other File based) is used then this work would not be necessary. In other words, perhaps it becomes a function only of data store components that are not local file based.
3.9 Cents/min. No Fees or Minimums!