Hi Listers,
I have a design question. Let me give a little run down of the
project. We are currently porting and enhancing an existing VB/ASP app to
C#/ASP.NET. The existing functionality uses COM+ Shared Property Manager
to store multiple static tables that get loaded upon the ASP
ApplicationStart event. These tables total about 35,000 rows. They are
used to decode information passed in by other components in the COM+
application. We decided to go with this approach because the volume of
decodes are very high and quite frequent so we need something memory
resident to do lookups on rather than hitting the DB everytime we needed to
do a lookup. This solution has worked fairly well but sometimes the SPM
looses it's mind and we have to restart the app in order to restore the
information in the SPM. This solution also had the side affect of forcing
a dependency upon the IIS process to load the SPM.
In moving to managed code we forsee our objects being used in a more
widespread fashion in both the web and desktop world. This being the case
we wanted to try to reduce the dependency upon the IIS process to load the
SPM as well as have the ability to reload the SPM at will. I have thought
through several scenerios that I am not entirely satisfied with. Here they
are:
Remoting:
Use remoting objects to decode values.
Pros: Universally available to all processes. Internal state of stored
information can be controlled external to the application needing the
decode.
Cons: Too slow for intended functionality. Calling accross a protocol
(http, tcp, etc) imposes a performance hit that is unacceptable.
Shared Property Manager:
Continue to use SPM.
Pros: Stable, Fast, already implemented.
Cons: Creates artificial dependencies of calling process to load SPM.
Can't be controlled external to the calling application.
Singleton Pattern:
Use a singleton pattern to load dataset into memory upon first access
and access decodes from it.
Pros: Fast on subsequent calls.
Cons: First call to the static decode method from process creates a long
wait. Subsequent calls very fast. Not controllable outside of application
scope.
COM Interop ROT/NT Service:
Write an NT Service that registers an object in the ROT that can be
accessed through COM interop by components in other applications.
Pros: Can be controlled from independantly of application. Dependant
on COM marshalling time imposed penalties should be fast enough for needs.
Cons: Not as straight forward to write or maintain. (i.e. requires
more work from me. :) ) Untested waters, will require initial time
investment that we can't afford to loose if things go wrong due to
deadlines that are set in stone. (Go figure)
Can anyone suggest anything else I might be missing. Does anyone know of a
way I could connect to a running NT Service besides a Singleton COM object,
registering it in the ROT, or Remoting? If I could get the SPM to work
cross process this would be ideal, but that's a pipe dream I do believe.
You help and insights are greatly appreciated.
John P. Sheppard
Ameren
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
