I'm reviewing an application that uses a local database for a .NET
application. In adding logic to automatically update components of the
application (content files, assemblies updates, and data updates) I found
that the original design locks the database while the app is running. This
means that the updater code needs to detect a runnning instance of the .NET
app and signal it to close down before it can apply database updates. This
makes it impossible to apply updates automatically.
It seems to me that tightly linking the database to the .NET app is
unnecessary. I see no reason why the database cannot be updated while the
application is running. The updater itself could lock portions of the
database during updating to prevent corruption and then signal the
application to refresh its in-memory data once the updates have been
committed.
I'd appreciate any feedback from others about this issue as I want to be
sure that I've thought through all the possibilities.
TIA.
Peter Bernhardt
SharpSense Software LLC
peter@.SharpBASSense.netURA
Peter Bernhardt wrote:
> I'm reviewing an application that uses a local database for a .NET
> application. In adding logic to automatically update components of the
> application (content files, assemblies updates, and data updates) I
> found that the original design locks the database while the app is
> running. This means that the updater code needs to detect a runnning
> instance of the .NET app and signal it to close down before it can
> apply database updates. This makes it impossible to apply updates
> automatically.
> It seems to me that tightly linking the database to the .NET app is
> unnecessary. I see no reason why the database cannot be updated while
> the application is running. The updater itself could lock portions of
> the database during updating to prevent corruption and then signal the
> application to refresh its in-memory data once the updates have been
> committed.
I obviously do not know the application and the archithecture behind it, but
your words seems to indicate a need for single access to the data...
I will not enter a discussion about the requirements theme selves as, again,
I'm completely ignorant about theme, and I think you have to deal with the
producer(s) for more details...
you say
>... then signal the
> application to refresh its in-memory data once the updates have been
> committed.
the application must support a way to be notified of such an underlying
manipulation of data to allow that, an this could imply an architectural
modification... and this could be a potential big deal, depending on the
original design..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
Friday, February 24, 2012
Local database and updates
Labels:
adding,
application,
automatically,
components,
database,
local,
logic,
microsoft,
mysql,
netapplication,
oracle,
reviewing,
server,
sql,
update,
updates
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment