G
Guest
Greetings,
My company has an ASP.NET based enterprise product that is undergoing some
changes and I need some community input to help solve a problem.
In the current implementation, any given installation of the product
supports only one database at a time. The server/db information is stored in
the registry on the computer hosting the com+ based middle tier. We are now
moving to a solution which supports multiple databases. That is, the user is
able to select from a list of available dbs at login.
Because of this change, the registry information the middle tier uses to
build up the db connection string is obviously no longer available. The key
information required now lives on the machine hosting the presentation layer
(web server). Since I want to avoid passing the server/db information with
every call into the middle tier, I have implemented a solution using
IISIntrinsics to retrieve Session information (where I store the server/db
properties). It works very well, but there is a great deal of consternation
from the powers that be about the implementation and the possible impact on
performance.
For IISIntrinsics to work, all the .aspx pages must have ASPCompat="true"
added to the Page directive. This now means that we move from our pages
running in MTA to running in STA. We have no native COM components running
on any of our pages, so it is frustrating to have to set this flag when all I
want are the Intrinsics of the page.
I am wondering how other people have implemented solutions where the
presentation layer has to provide the middle tier with connection
information. I understand that Whidbey will not support ASPCompat, so does
anyone know if there will be a way to retrieve Session data from a com+
component hosted on another machine?
Cheers, Ian Williamson
My company has an ASP.NET based enterprise product that is undergoing some
changes and I need some community input to help solve a problem.
In the current implementation, any given installation of the product
supports only one database at a time. The server/db information is stored in
the registry on the computer hosting the com+ based middle tier. We are now
moving to a solution which supports multiple databases. That is, the user is
able to select from a list of available dbs at login.
Because of this change, the registry information the middle tier uses to
build up the db connection string is obviously no longer available. The key
information required now lives on the machine hosting the presentation layer
(web server). Since I want to avoid passing the server/db information with
every call into the middle tier, I have implemented a solution using
IISIntrinsics to retrieve Session information (where I store the server/db
properties). It works very well, but there is a great deal of consternation
from the powers that be about the implementation and the possible impact on
performance.
For IISIntrinsics to work, all the .aspx pages must have ASPCompat="true"
added to the Page directive. This now means that we move from our pages
running in MTA to running in STA. We have no native COM components running
on any of our pages, so it is frustrating to have to set this flag when all I
want are the Intrinsics of the page.
I am wondering how other people have implemented solutions where the
presentation layer has to provide the middle tier with connection
information. I understand that Whidbey will not support ASPCompat, so does
anyone know if there will be a way to retrieve Session data from a com+
component hosted on another machine?
Cheers, Ian Williamson