In this main IIS process and ASP.NET application run in the same process. SO, if any one crashes the other is also affected. Example lets say I have hosted Yahoo Hotmail, Amazon and Google on a single PC. So, all applications and IIS process runs on the same process. In case any website crashes it affects everyone.
In Medium pooled scenario the IIS and Web-application runs in different process. So, in this case there are two processes: process1 and process2. In Proess1 the IIS process is running and in Process2 we have all web-applications running.
In High Isolated scenario every process is running in their own process. This consumes heavy memory but has highest reliability
Pooled out-of-process. Protected from the effects of applications that run in High isolation; however, the applications are not protected from each other.
Out-of-process. Protected from the effects of other applications that run in Medium or High isolation; cannot affect other applications running on the same computer.
Note: Applicable to IIS 5.0
Geek is back.
If you feel this is helpful, RATE IT.
1. Read Uncommitted (or commonly known as Dirty Read): In this level of isolation, there is absolutely no shared lock or exclusive lock to be applied on our data. What this implies is that what you are actually reading is data that is uncommitted and not locked and therefore, this gives room for other processes to modify the data you are reading and invariably, there is a possibility that you might end up reading data that is wrong. It also means that incase you are reading data that is being read within an uncommitted transaction, a rollback transaction might change the data that SQL Server might have read thereby making the data which you have seen on your end, simply erroneous. I guess you figured out that we already had a look at this type of data earlier in this post and we call it by its common term: dirty data since it came from an uncommitted read or a dirty read. The other side of the equation is that this type of read gives the best concurrency as no lock is applied anywhere and therefore, it is feasible to consider this type of an isolation for your system after critical scrutiny.
Syntax: SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
2. Read Committed: This isolation level ensures that shared locks are acquired while reading data which means that as long as long as data is being read, a lock is applied on that piece of data. This ensures that you do not read dirty data or data from uncommitted transactions. This is the default level of isolation that SQL Server provides. There is however another aspect to this isolation level: Once a process has finished reading this data, the shared lock is removed even before the transaction has ended. Hence, dirty reads can be avoided but there are situations where the other scenarios which we have listed can occur.
Syntax: SET TRANSACTION ISOLATION LEVEL READ COMMITTED
3. Repeatable Read: This is a higher level of isolation thereby ensuring more consistency but lesser concurrency. Here, a shared lock is requested while reading data thereby ensuring that no dirty read occurs. However, note that earlier when we talked about the Read Committed transaction, we mentioned that a shared lock is acquired ONLY during a read and that the lock is released even before the actually transaction ends.
In a repeatable read isolation mode however, this is not the case since we are allowing the shared lock to be held till the transaction gets over. This ensures that not only are dirty reads avoided, but even consistent results are possible because lost updates do not occur. Further, it is possible to have repeatable reads, as against the common consistency problems we saw (under 3. non-repeatable reads scenario).
Syntax: SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
4. Serializable:: This is an extremely restrictive option which holds shared locks on ranges of data and is used to avoid phantom reads. This isolation mode does not allow insertion or deletion of rows that are locked. The actual mechanism is that an active transaction will obtain key range locks based on different query filters. By query filters, we mean all possible data that can come from a table that match the filter. Hence, we are locking a good chunk of the table to make sure that no insertions or deletions are possible. This leads to a ton of contention issues (much better than older versions of SQL Server where an entire page or table was locked!) as more data was locked than what was actually necessary.
Syntax: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
1.Low(IIS Process)- In this setting, ASP Pages are executed in-process.This is the fastest setting and it is default under IIS 4.The major disadvantage of this level is that if ASP crashes, IIS crashes as well and must be restarted.
2.Medium(Pooled) - In this setting, ASP Pages are executed in different process. If ASP crashes, IIS won't crash. So, It is more reliable compared to Low Isolation Level.
3.High(Isolated) - In this setting, Each ASP application runs out-process(ie) in its own process space. The advantage is that If ASP Application crashes neither IIS nor any other ASP Application crashes.. The disadvantage is that this setting consume more memory.
Please rate this post, if it is useful for you.
Thanks & Regards
* Low (IIS Process): ASP pages run in INetInfo.Exe, the main IIS process, therefore they are executed in-process. This is the fastest setting, and is the default under IIS4. The problem is that if ASP crashes, IIS crashes as well and must be restarted (IIS5 has a reliable restart feature that automatically restarts a server when a fatal error occurs).
* Medium (Pooled): In this case ASP runs in a different process, which makes this setting more reliable: if ASP crashes IIS won't. All the ASP applications at the Medium isolation level share the same process, so you can have a web site running with just two processes (IIS and ASP process). IIS5 is the first Internet Information Server version that supports this setting, which is also the default setting when you create an IIS5 application. Note that an ASP application that runs at this level is run under COM+, so it's hosted in DLLHOST.EXE (and you can see this executable in the Task Manager).
* High (Isolated): Each ASP application runs out-process in its own process space, therefore if an ASP application crashes, neither IIS nor any other ASP application will be affected. The downside is that you consume more memory and resources if the server hosts many ASP applications. Both IIS4 and IIS5 supports this setting: under IIS4 this process runs inside MTS.EXE, while under IIS5 it runs inside DLLHOST.EXE.
When selecting an isolation level for your ASP application, keep in mind that out-process settings - that is, Medium and High - are less efficient then in-process (Low). However, out-process communication has been vastly improved under IIS5, and in fact IIS5's Medium isolation level often deliver better results than IIS4's Low isolation. In practice, you shouldn't set the Low isolation level for an IIS5 application unless you really need to serve hundreds pages per second.
IIS has three level of isolation:-
LOW (IIS process):- In this main IIS, process, and ASP.NET application run in same process. So if any one crashes the other is also affected. Example let us say (well this is not possible) I have hosted yahoo, hotmail .amazon and goggle on a single PC. So all application and the IIS process runs on the same process. In case any website crashes, it affects every one.
Medium (Pooled):- In Medium pooled scenario, the IIS, and web application run in different process. Therefore, in this case there are two processes process1 and process2. In process1, the IIS process is running and in process2, we have all Web application running
High (Isolated):-In high isolated scenario every process is running is there own process. In below figure there are five processes and every one handling individual application. This consumes heavy memory but has highest reliability.