| CATEGORII DOCUMENTE |
| Asp | Autocad | C | Dot net | Excel | Fox pro | Html | Java |
| Linux | Mathcad | Photoshop | Php | Sql | Visual studio | Windows | Xml |
In this section of the chapter we will take a look at two larger examples. First, we'll take a look at creating thread-safe wrappers and then move on to a database connection pool.
The general idea of writing our own wrapper comes from the fact that you may not want to make every class in our library thread-safe, as synchronization has performance penalties associated with it. You would like to give the application developer a choice of whether to use a synchronized class or not. As the application developer would neither like to take the risk of a deadlock nor want to pay the performance penalty of using a thread-safe class in a single-threaded environment, they might prefer to have a choice of having a built-in synchronized wrapper for the same class in the library rather than writing a specific one. Collection classes like ArrayList and Hashtable in the System.Collections namespace already have this feature. You can decide whether you want to use a thread-safe Hashtable or not during initialization of the Hashtable. You can initialize a thread-safe Hashtable by calling the shared Synchronized() method of the Hashtable class as shown below:
Hashtable h;It would be good to give the application developer such a choice. In this example, we will attempt to develop a class and a synchronized wrapper for the class. We will develop a Book Collection library and Figure 4 shows the UML representation of the Book Collection library.
The program is very simple, but the concept of having intrinsic synchronization support is very important. By adding intrinsic synchronization support to our library, we will allow the developer to choose between a synchronized and non-synchronized environment for the same class. For example, programmers who do not need synchronization can instantiate an object as follows:
BookLib b = new BookLib()while programmers who use our type in a thread-hot environment can use the thread-safe wrappers as follows:
BookLib b = new BookLib()The following is the complete BookLib.cs source along with its synchronized wrapper:
using System;In the above example, we first declare an interface IBookCollection, which has the following methods and properties for handling collection of books:
Clear() - Method to clear the book collection
Add() - Method to add a book to the book collection
GetBook() - Method to get a book from the book collection
IsSynchronized() - Read-only property used to check whether the collection is synchronized or not
SyncRoot() - Read-only property to get the synchronized root of the collection
Next we declare a class called Book representing a book in the collection. For example, the collection might be a library or a book store, but the representation of the Book class is the same in both.
The BookLib class implements the IBookCollection interface. As a result, the BookLib class must implement all the methods and properties of the IBookCollection interface. We declare a Hashtable called bk as the collection that will contain our books. The Key of the Book object will be its ISBN number. In the Add() method, we add a Book object to the Hashtable. In the GetBook() method, we retrieve the Book object if its ISBN number is supplied.
Now we must address any synchronization issues. In the Synchronized() method, we create an object of type SyncBookLib and return a reference to it. SyncBookLib is the synchronized version of the BookLib class. SyncBookLib inherits from the BookLib class, thus inheriting all the properties and methods that the BookLib class has already implemented. The difference between SyncBookLib and BookLib class is that in the SyncBookLib class, we lock all the critical sections using monitors (using the lock keyword). For example, the Clear(), GetBook(), and Add() methods have locks in their implementations thus making them thread-safe, whereas, in the BookLib class, there are no locks in any of the methods.
In the Test class, we create a synchronized BookLib if we pass any command-line argument. If there are no command-line arguments passed, we create a non thread-safe BookLib object. Then we create three threads that add some books to our book library. When you run the application, the difference between the execution of synchronized BookLib and non-synchronized BookLib will be clear. In the synchronized version, only one thread can access the library at any point of time. So, the other two threads have to wait until the first thread has finished adding books to the BookLib. This is not the case if we use the non-synchronized version; all the threads are given concurrent access to the BookLib object instance.
The output from BookLib with a command-line argument (thread-safe) will be as follows:
The output from BookLib with no command-line argument (non-thread-safe will be as follows:
Adding Book for ThreadID:3Object pools are very common in enterprise software development where instantiation of objects has to be controlled in order to improve the performance of the application. For example, database connections are expensive objects to be created every time we need to connect to a database. So, instead of wasting resources in instantiating the database connection for every database call, we can pool and reuse some connection objects that we have already created and thus gain a performance advantage by saving the time and resources required to create a new connection object for every database call.
Object pooling is similar to a book library. The book library maintains a pool of similar books. When the demand for that particular book increases, the library buys more, else the readers just keep on reusing the same books. In Object Pooling, first we check the pool to see whether the object has already been created and pooled, if it is pooled, we get the pooled object; else we create a new one and pool it for future use. Object pooling is extensively used in large-scale application servers like Enterprise Java Beans (EJB) Servers, MTS/COM+, and even the .NET Framework.
In this section, we will develop a database connection pool for pooling database connections. Database connections are expensive to create. In a typical web application there might be thousands of users trying to access the web site at the same time. If most of these hits need database access to serve dynamic data and we go on creating new database connection for each user, we are going to affect the application performance negatively. Creating a new object requires new memory allocation. Memory allocation reduces application performance and, as a result, the web site will either slow down considerably in delivering the dynamic content, or crash after a critical point is reached. Connection pooling maintains a pool of created objects, so the application that needs a database connection can just borrow a connection from the pool and then return it to the pool when the job is done, rather than creating a new database connection. Once data is served to one user, the connection will be returned back to the pool for future use.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 706
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
