|
From: Dejan K. <dej...@ya...> - 2004-03-21 11:16:59
|
Hi Mike, First of all, I must say that I have never used that code so I am probably not aware of all issues regarding to SQlConfig. I know that Erik has some problems with initial SqlConfig implementation since his system was required to run in clustered enviroment where all nodes should be aware of changes made in one node (without restarting). So, (if I remember well) he dropped all cache usage in SqlConfig and every change made in configuration is immediatelly written to database. Now, I am not sure if this could be done better. Perhaps, you could introduce some new config option that would enable cache usage in SqlConfig. I am not sure if this is all true, but you could search mailing list. Also, I guess that old SqlConfig(Service) implementation is still in CVS so you can look at the CVS history for these files. regards, Dejan --- Michael Ansley <mic...@ze...> wrote: > Hi, > > When a setString() is called on a SQLConfig object, > it immediately > passes the values to it's server (a > SQLConfigService, funnily enough), > which writes it to the database. In addition, the > saveConfig method on > the SQLConfigService class doesn't do anything. > > I was thinking, it makes more sense to me if the > setString() call does > *not* pass the call to the service object and save > immediately to the > database, but simply changes it's own cache value. > Then, when some or > other client code calls to saveConfig() on the > SQLConfigService, that's > when the service retrieves the cached updates and > the data gets written > back to the database. That way it can all be done > in a single > transaction, as well. > > Thoughts, please, anybody who cares, one way or the > other... > > Cheers... > > > MikeA > > > > ATTACHMENT part 2 application/pgp-signature name=signature.asc __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html |