In general, ASP. NET is always an application that is accessed by multiple users. For IIS and ASP. but by default, XPO Data Layer only creates one database connection object. When two users access the database at the same time, the last user must wait until the query of the previous user ends.
Theoretically, we can create a DataLayer for every Page or even every user access, but creating a DataLayer is a relatively expensive process. This is not realistic. If there is a set of database connection objects and XPO automatically selects the first idle object for the next query, this is a great practice.
Fortunately, ThreadSafeDataLayer can already handleDataStoreFork. Simply put, we can create an IDataStore object array, initialize a DataStoreFork, and then use them to construct a ThreadSafeDataLayer.
1 // C #
2 IDataStore GetDataStore (){
3 string connStr = ConfigurationManager. ConnectionStrings ["PrimaryConnection"]. ConnectionString;
4 SqlConnection conn = new SqlConnection (connStr );
5 IDataStore store = new MSSqlConnectionProvider (conn, AutoCreateOption. SchemaAlreadyExists );
6 return store;
7}
8
9 IDataLayer GetDataLayer (){
10 ReflectionDictionary dict = new ReflectionDictionary ();
11 dict. CollectClassInfos (typeof (Person). Assembly );
12
13 const int maxConnections = 3;
14 IDataStore [] stores = new IDataStore [maxConnections];
15 for (int I = 0; I <maxConnections; I ++)
16 stores [I] = GetDataStore ();
17
18 return new ThreadSafeDataLayer (dict, new DataStoreFork (stores ));
19}
Note that maxConnections should not exceed the number of CPU cores of the database server.
In addition, in general ASP. NET projects, doing so will not bring significant performance improvements. In case of performance problems, we should not immediately adopt this approach, but should first eliminate performance bottlenecks elsewhere.
DataStoreFork is more suitable for other scenarios where multiple users, such as Web services, access concurrently.
XPO to Database Connectivity: Mastering Fork
Etiquette