RE: Retrieving state information from a middle tier
From: Ian Williamson (IanWilliamson_at_discussions.microsoft.com)
Date: 02/25/05
- Next message: Guest: "Re: Saving Excel document blows up Infragistics menu in frame"
- Previous message: Scott Allen: "Re: "Building Blocks" are "Application Blocks""
- In reply to: Ian Williamson: "Retrieving state information from a middle tier"
- Next in thread: Vaibhav: "Re: Retrieving state information from a middle tier"
- Reply: Vaibhav: "Re: Retrieving state information from a middle tier"
- Reply: inetmug: "RE: Retrieving state information from a middle tier"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 25 Feb 2005 12:33:05 -0800
I will try to be more concise.
We have a presentation tier hosted on a web server where all our .aspx pages
and associated code behind live. We have a middle tier which is made up of a
number of COM+ libraries. These two tiers currently reside on the same
computer, but the long term vision is to implement .NET remoting to allow the
tiers to be physically separated.
The current implementation only allows for one database to be served up.
Because of this, the middle tier is used to host the server and database name
in the registry. Our clients may have multiple databases that support the
application (test, training, production, etc). For them to change between
databases, they have to modify the registry and then cycle IIS so that the
associated caches are reloaded with the appropriate data from the newly
specified database.
We now wish to support multiple database connections. So, when a user logs
into the application, not only do they specify user name and password, they
also pick from a list of available databases (test, training, production,
etc). Since the database connection is now associated to a user, we can no
longer use the middle tier as the source of the connection properties.
Everytime data is requested, there must be some mechanism to specify which
server and database the data should be pulled from. The nasty brute force
method is to pass this information along with every call from the web page
into the middle tier. In my research, I found that you could expose the ASP
Intrinsics of a page and consume them from a serviced component.
When a user logs in, the server and database they have selected is stored to
the Session object. When a request is made from one of the pages to retrieve
data, the middle tier retrieves this Session information using the following:
ASPTypeLibrary.Session oSession =
(ASPTypeLibrary.Session)ContextUtil.GetNamedProperty("Session");
This call utilizes the ASPTypeLibrary COM library.
For a web page to be able to expose it's Intrinsics, the property
ASPCompat="true" must be added to the Page directive. By setting this
property, the page now executes in a Single Threaded Apartment (STA) as
opposed to it's default Multi Threaded Apartment (MTA). Various articles
point to the fact that this may impact performance and cause deadlocks.
My question is, how have other people implemented solutions where they need
to specify connection properties across tiers.
Is there a simpler way of persisting my connection properties into my middle
tier? (I know almost nothing of COM+)
Is the solution I am using common?
Are the performance issues significant?
Whidbey will apparently no longer support ASPCompat, so are new methods
being established to be able to retrieve information from the caller?
Thank you.
- Next message: Guest: "Re: Saving Excel document blows up Infragistics menu in frame"
- Previous message: Scott Allen: "Re: "Building Blocks" are "Application Blocks""
- In reply to: Ian Williamson: "Retrieving state information from a middle tier"
- Next in thread: Vaibhav: "Re: Retrieving state information from a middle tier"
- Reply: Vaibhav: "Re: Retrieving state information from a middle tier"
- Reply: inetmug: "RE: Retrieving state information from a middle tier"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|