Re: Current approach to fast n tier oracle design

John Warner <[email protected]>
Newsgroups gmane.comp.windows.devel.dotnet.advanced
Organization House
Message-ID <0b5601c98391$78cbab80$6a630280$@com>
Can't understand why people do not consider the archive and those who
might be doing a Google search for the issue they are having. The App Pool
has what to do with Oracle? So this thread is effectively worthless to
someone else with the same problem. On behave of the next person with this
app pool issue, thanks for nothing.

John Warner


> -----Original Message-----
> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> [email protected]] On Behalf Of Frans Bouma
> Sent: Saturday, January 31, 2009 3:47 AM
> To: [email protected]
> Subject: Re: [ADVANCED-DOTNET] Current approach to fast n tier oracle
> design
> 
> (you should have changed the subject line)
> 
> > I am looking for an answer to a question regarding the AppPool and
.NET
> > dlls. If I set up multiple app pools, and assign web apps to the app
> pools.
> > Each web app would be pointing to the same code base (this is a portal
app
> > set up).
> >
> > Question is, are .NET dlls shared (in physical memory) like regular
> Windows
> > DLLs?
> >
> > We are worried about physical memory (and thrashing)...
> 
> 	If dll size is your biggest concern, you should place more memory
> than 32MB. ;)
> 
> 	Seriously, even if dll's are several MB's in size, they're not
> eating memory. Data is. So if you're concerned about memory consumption,
> examine how much memory for data your app is allocating.
> 
> 		FB
> 
> ===================================
> View archives and manage your subscription(s) at
> http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.