What Is Multithreading?
Multithreading is a technique that can be used to perform time consuming tasks in a separate additional thread other than the main application thread.
When you, for example, have a time-consuming function, you may need to call this function as a response of a button click. Now, instead of freezing all your application waiting for this function to return / to finish, you can create a new thread and assign this function to. When you do this, your application interface will not be blocked and you can use it to perform other tasks. At the same time, your time-consuming task is being carried out in the background.
You can think of it as the two threads: the main one, and the newly created one. Both are running in parallel, and this improves the performance and responsiveness of your application.
Advantages and Disadvantages of Using Multithreading
Despite improving your application's performance, and avoiding unresponsive user interface, multithreading has the following disadvantages:
* There is a runtime overhead associated with creating and destroying threads. When your application creates and destroys threads frequently, this overhead affects the overall application performance.
* Having too many threads running at the same time decreases the performance of your entire system. This is because your system is attempting to give each thread a time slot to operate inside.
* You should design your application well when you are going to use multithreading, or otherwise your application will be difficult to maintain and extend.
* You should be careful when you implement a multithreading application, because threading bugs are difficult to debug and resolve.
Notes:
* Each time a thread is created, a certain amount of memory is consumed to hold this thread context information. Hence, the number of threads that can be created is limited by the amount of available memory.
* More threads does not mean a faster responsive application, instead it can decrease the performance of your application.
The Thread Pool
Instead of creating a thread each time we need one, and then destroying it after finishing, the .NET framework introduces the concept of thread pool. In the thread pool technique, and instead of creating a new thread whenever you need one, your application will obtain a thread from the thread pool. After that obtained thread completes its task, it will be returned to the thread pool instead of destroying it - waiting for the next acquiring. This reusability increases the overall application performance, and reduces the cost of excessive thread creation and termination.
To make use of this technique, you need to use the System.Threading.ThreadPool class. The thread pool will be created the first time you use it. The number of total threads in this pool is restricted by default to 25 threads. This means that all of these 25 threads may be busy at some point. If you need to acquire a new thread at this point, your task will be scheduled waiting for a thread to finish its task and return to the pool.
Sunday, February 28, 2010
Wednesday, February 24, 2010
4 - Tier Architecture
See the 3-tier architecture in Microsoft
1. Business Object [BO]
2. Business Access Layer [BAL]
3. Data Access Layer [DAL]
4. Presentation Layer
Business Object(BO)
class employee.cs
{
int employeeID= 0;
string m_FirstName = string.Empty;
string m_LastName = string.Empty;
int salary= 0;
#region Propertiers
public int employeeID
{
get { return employeeID; }
set { employeeID = value; }
}
public string FirstName
{
get { return m_FirstName; }
set { m_FirstName = value; }
}
public string LastName
{
get { return m_LastName; }
set { m_LastName = value; }
}
public int Salary
{
get { return salary; }
set { salary = value; }
}
#endregion Properties
2. Business Access Layer [BAL]
using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
///
/// Summary description for PersonBAL
///
public class EmployeeBAL
{
public EmployeeBAL()
{
}
///
/// insert records into database
///
///
///
public int Insert(Employee employee)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Insert(person);
}
catch
{
throw;
}
}
///
/// Update records into database
///
///
///
public int Update(Employee employee)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Update(person);
}
catch
{
throw;
}
}
///
/// Load records from database
///
///
public DataTable Load()
{
EmployeeDAL eDAL = new employeeDAL();
try
{
return eDAL.Load();
}
catch
{
throw;
}
finally
{
eDAL = null;
}
}
///
/// Delete record from database
///
///
///
public int Delete(Person person)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Delete(person);
}
catch
{
throw;
}
finally
{
eDAL = null;
}
}
}
3. Data Access Layer [DAL]
this is also contains in App_Code folder and contains all the code to access database.
4. Presentation Layer
This Layer contains the UI.
See the 3-tier architecture in Microsoft
1. Business Object [BO]
2. Business Access Layer [BAL]
3. Data Access Layer [DAL]
4. Presentation Layer
Business Object(BO)
class employee.cs
{
int employeeID= 0;
string m_FirstName = string.Empty;
string m_LastName = string.Empty;
int salary= 0;
#region Propertiers
public int employeeID
{
get { return employeeID; }
set { employeeID = value; }
}
public string FirstName
{
get { return m_FirstName; }
set { m_FirstName = value; }
}
public string LastName
{
get { return m_LastName; }
set { m_LastName = value; }
}
public int Salary
{
get { return salary; }
set { salary = value; }
}
#endregion Properties
2. Business Access Layer [BAL]
using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
///
/// Summary description for PersonBAL
///
public class EmployeeBAL
{
public EmployeeBAL()
{
}
///
/// insert records into database
///
///
///
public int Insert(Employee employee)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Insert(person);
}
catch
{
throw;
}
}
///
/// Update records into database
///
///
///
public int Update(Employee employee)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Update(person);
}
catch
{
throw;
}
}
///
/// Load records from database
///
///
public DataTable Load()
{
EmployeeDAL eDAL = new employeeDAL();
try
{
return eDAL.Load();
}
catch
{
throw;
}
finally
{
eDAL = null;
}
}
///
/// Delete record from database
///
///
///
public int Delete(Person person)
{
EmployeeDAL eDAL = new EmployeeDAL();
try
{
return eDAL.Delete(person);
}
catch
{
throw;
}
finally
{
eDAL = null;
}
}
}
3. Data Access Layer [DAL]
this is also contains in App_Code folder and contains all the code to access database.
4. Presentation Layer
This Layer contains the UI.
See the 3-tier architecture in Microsoft
Thursday, February 18, 2010
Tips on how to avoid deadlocking on your SQL Serve
# Ensure the database design is properly normalized.
# Have the application access server objects in the same order each time.
# During transactions, don't allow any user input. Collect it before the transaction begins.
# Avoid cursors.
# Keep transactions as short as possible. One way to help accomplish this is to reduce the number of round trips between your application and SQL Server by using stored procedures or keeping transactions with a single batch. Another way of reducing the time a transaction takes to complete is to make sure you are not performing the same reads over and over again. If your application does need to read the same data more than once, cache it by storing it in a variable or an array, and then re-reading it from there, not from SQL Server.
# Reduce lock time. Try to develop your application so that it grabs locks at the latest possible time, and then releases them at the very earliest time.
# If appropriate, reduce lock escalation by using the ROWLOCK or PAGLOCK.
# Consider using the NOLOCK hint to prevent locking if the data being locked is not modified often.
# If appropriate, use as low of an isolation level as possible for the user connection running the transaction.
# Consider using bound connections.
# Have the application access server objects in the same order each time.
# During transactions, don't allow any user input. Collect it before the transaction begins.
# Avoid cursors.
# Keep transactions as short as possible. One way to help accomplish this is to reduce the number of round trips between your application and SQL Server by using stored procedures or keeping transactions with a single batch. Another way of reducing the time a transaction takes to complete is to make sure you are not performing the same reads over and over again. If your application does need to read the same data more than once, cache it by storing it in a variable or an array, and then re-reading it from there, not from SQL Server.
# Reduce lock time. Try to develop your application so that it grabs locks at the latest possible time, and then releases them at the very earliest time.
# If appropriate, reduce lock escalation by using the ROWLOCK or PAGLOCK.
# Consider using the NOLOCK hint to prevent locking if the data being locked is not modified often.
# If appropriate, use as low of an isolation level as possible for the user connection running the transaction.
# Consider using bound connections.
Wednesday, February 17, 2010
Relation Between Application Domains and Assemblies
Most development and runtime environments has a definition for the building blocks of an application. Assemblies are the building blocks of .NET framework applications. They are the fundamental unite of deployment. An assembly consists of types and resources working together to form a logical unit of the functionality of your application. You can divide your .NET application into assemblies. The assembly file can have an .EXE or a .DLL extension.
As we mentioned previously, you can run more than one application domain within your application. Each application domain will run a given piece of code. An assembly is simply the piece of code we mean here. So, each application domain can run an assembly within the entire application. This is the relation between application domains and assemblies.
As we mentioned previously, you can run more than one application domain within your application. Each application domain will run a given piece of code. An assembly is simply the piece of code we mean here. So, each application domain can run an assembly within the entire application. This is the relation between application domains and assemblies.
AppDomain and .Net Developer
You’ve created two ASP.NET applications on the same server, and have not done any special configuration. What is happening?
A single ASP.NET worker process will host both of the ASP.NET applications. On Windows XP and Windows 2000 this process is named aspnet_wp.exe, and the process runs under the security context of the local ASPNET account. On Windows 2003 the worker process has the name w3wp.exe and runs under the NETWORK SERVICE account by default.
An object lives in one AppDomain. Each ASP.NET application will have it’s own set of global variables: Cache, Application, and Session objects are not shared. Even though the code for both of the applications resides inside the same process, the unit of isolation is the .NET AppDomain. If there are classes with shared or static members, and those classes exist in both applications, each AppDomain will have it’s own copy of the static fields – the data is not shared. The code and data for each application is safely isolated and inside of a boundary provided by the AppDomain
In order to communicate or pass objects between AppDomains, you’ll need to look at techniques in .NET for communication across boundaries, such as .NET remoting or web services.
Note again: the one caveat to the idea of an AppDomain as a boundary is that ASP.NET applications will run with full trust by default. Fully trusted code can execute native code, and native code can essentially have access to anything inside the process. You’ll need to run applications with partial trust to restrict access to unmanged code and verify all managed code to secure AppDomains.
A single ASP.NET worker process will host both of the ASP.NET applications. On Windows XP and Windows 2000 this process is named aspnet_wp.exe, and the process runs under the security context of the local ASPNET account. On Windows 2003 the worker process has the name w3wp.exe and runs under the NETWORK SERVICE account by default.
An object lives in one AppDomain. Each ASP.NET application will have it’s own set of global variables: Cache, Application, and Session objects are not shared. Even though the code for both of the applications resides inside the same process, the unit of isolation is the .NET AppDomain. If there are classes with shared or static members, and those classes exist in both applications, each AppDomain will have it’s own copy of the static fields – the data is not shared. The code and data for each application is safely isolated and inside of a boundary provided by the AppDomain
In order to communicate or pass objects between AppDomains, you’ll need to look at techniques in .NET for communication across boundaries, such as .NET remoting or web services.
Note again: the one caveat to the idea of an AppDomain as a boundary is that ASP.NET applications will run with full trust by default. Fully trusted code can execute native code, and native code can essentially have access to anything inside the process. You’ll need to run applications with partial trust to restrict access to unmanged code and verify all managed code to secure AppDomains.
Advantages of .NET AppDomain
You may ask, why should I create more than one application domain within my application?
The following advantages of application domains answer this question.
* In terms of isolation, code running in one application domain can not access code or resources running in another application domain.
* In terms of security, you can run more than one set of web controls in a single browser process. Each set of them is running in a separate application domain so each one can not access the data or resources of the other sets. You can control the permissions granted to a given piece of code by controlling the application domain inside which the code is running.
* In terms of robustness, fault in code running in one application domain can not affect other applications although they all are running inside the same process. Individual application domain can be stopped without stopping the entire process, you can simply unload the code running in a single application domain.
So, from the above advantages, you can observe that by using application domains you can create rather robust .NET applications. It increases isolation, stability, and security of your application.
The following advantages of application domains answer this question.
* In terms of isolation, code running in one application domain can not access code or resources running in another application domain.
* In terms of security, you can run more than one set of web controls in a single browser process. Each set of them is running in a separate application domain so each one can not access the data or resources of the other sets. You can control the permissions granted to a given piece of code by controlling the application domain inside which the code is running.
* In terms of robustness, fault in code running in one application domain can not affect other applications although they all are running inside the same process. Individual application domain can be stopped without stopping the entire process, you can simply unload the code running in a single application domain.
So, from the above advantages, you can observe that by using application domains you can create rather robust .NET applications. It increases isolation, stability, and security of your application.
Application Domain or AppDomain
.NET introduces the concept of an application domain, or AppDomain. Like a process, the AppDomain is both a container and a boundary. The .NET runtime uses an AppDomain as a container for code and data, just like the operating system uses a process as a container for code and data. As the operating system uses a process to isolate misbehaving code, the .NET runtime uses an AppDomain to isolate code inside of a secure boundary.
Note, however, that the application domain is not a secure boundary when the application runs with full trust. Applications running with full trust can execute native code and circumvent all security checks by the .NET runtime. ASP.NET applications run with full trust by default.
An AppDomain belongs to only a single process, but single process can hold multiple AppDomains. An AppDomain is relatively cheap to create (compared to a process), and has relatively less overhead to maintain than a process. For these reasons, an AppDomain is a great solution for the ISP who is hosting hundreds of applications. Each application can exist inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost savings.
Note, however, that the application domain is not a secure boundary when the application runs with full trust. Applications running with full trust can execute native code and circumvent all security checks by the .NET runtime. ASP.NET applications run with full trust by default.
An AppDomain belongs to only a single process, but single process can hold multiple AppDomains. An AppDomain is relatively cheap to create (compared to a process), and has relatively less overhead to maintain than a process. For these reasons, an AppDomain is a great solution for the ISP who is hosting hundreds of applications. Each application can exist inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost savings.
Friday, February 12, 2010
Top 10 Mistakes on SQL SERVER
10. Unknown Scalability Requirements
9. Improperly Normalized Tables
8. Improper Indexing
7. No Baseline or Benchmarks
6. Disks — Thinking about Space but Not I/O
5. Lack of Error Notification
4. Poor or Nonexistent Backup Strategy
3. Lack of Query Tuning and Optimization
2. Ignorance of Internals
1. Overuse of Cursors
9. Improperly Normalized Tables
8. Improper Indexing
7. No Baseline or Benchmarks
6. Disks — Thinking about Space but Not I/O
5. Lack of Error Notification
4. Poor or Nonexistent Backup Strategy
3. Lack of Query Tuning and Optimization
2. Ignorance of Internals
1. Overuse of Cursors
Benefits of Stored Procedures
Modular programming :
You can write a stored procedure once, then call it from multiple places in your application.
Performance
Stored procedures provide faster code execution and reduce network traffic.
* Faster execution: Stored procedures are parsed and optimized as soon as they are created and the stored procedure is stored in memory. This means that it will execute a lot faster than sending many lines of SQL code from your application to the SQL Server. Doing that requires SQL Server to compile and optimze your SQL code every time it runs.
* Reduced network traffic: If you send many lines of SQL code over the network to your SQL Server, this will impact on network performance. This is especially true if you have hundreds of lines of SQL code and/or you have lots of activity on your application. Running the code on the SQL Server (as a stored procedure) eliminates the need to send this code over the network. The only network traffic will be the parameters supplied and the results of any query.
Security
Users can execute a stored procedure without needing to execute any of the statements directly. Therefore, a stored procedure can provide advanced database functionality for users who wouldn't normally have access to these tasks, but this functionality is made available in a tightly controlled way.
You can write a stored procedure once, then call it from multiple places in your application.
Performance
Stored procedures provide faster code execution and reduce network traffic.
* Faster execution: Stored procedures are parsed and optimized as soon as they are created and the stored procedure is stored in memory. This means that it will execute a lot faster than sending many lines of SQL code from your application to the SQL Server. Doing that requires SQL Server to compile and optimze your SQL code every time it runs.
* Reduced network traffic: If you send many lines of SQL code over the network to your SQL Server, this will impact on network performance. This is especially true if you have hundreds of lines of SQL code and/or you have lots of activity on your application. Running the code on the SQL Server (as a stored procedure) eliminates the need to send this code over the network. The only network traffic will be the parameters supplied and the results of any query.
Security
Users can execute a stored procedure without needing to execute any of the statements directly. Therefore, a stored procedure can provide advanced database functionality for users who wouldn't normally have access to these tasks, but this functionality is made available in a tightly controlled way.
Subscribe to:
Posts (Atom)