Use of Web application database connection

The previous post was a big wave, and the bricks were so busy. The previous post views are not clear and accurate. We should first say sorry, resort the ideas, and then describe them separately.

Point of View: For a webapplication, to improve the overall throughput, we should start from improving the single-page response capability. For a webapplication using an atomic operation: to open a page, the fewer data connections opened during the lifecycle of the page, the less the number of open and closed times, the higher the efficiency.

Constraint: the page is a synchronous operation by default. When we agree that asynchronous operations will not be used here, if asynchronous operations are used for optimization, there will be another problem, for example, when two operations have a relationship between causes and consequences.

The first is about database connection. I am using a database connection instead of a connection here to keep the database from leaking, saving the trouble of confusing Guan Gong When Qin Qiong AND THE xxconnection object of. net.
Used hereCodeI will use the implementation of nhib.pdf as an example to ensure that the viewpoint is neutral.
Now, we are wronged to use nhib.pdf for the moment.
We are faced with two problems here: database connection access where objects are stored, and the second is how to use them. If some people choose to enable them as needed, they will open them as needed. For example

Isession vsession = Mcfg. buildsessionfactory (). opensession (); // To create a session factory, a singleton object should be used to encapsulate the session factory.

Itransaction vtransaction = Vsession. begintransaction (); // Create Transaction Processing

Try

{< br>
vsession. save (ventity); /// add data to a database

vtransaction. commit ();
labmessage. text = " OK " ;< br>
}

Catch (Exception ex)

{

Vtransaction. rollback ();

Labmessage. Text="Error"+Ex. tostring ();

}

Finally

{

Vsession. Close ();

}

This code is from http://www.cnblogs.com/surprise/archive/2004/10/13/51701.aspx

Generally, we will put this code into an object that processes the business logic. In, when you need to add an entity, you can call it. Of course, entity has more usage, but here we will give the first example for a simple example.

If we encapsulate a logic for this simple object: Adding XX (user information, post), etc. When we need to operate multiple objects on one page, there will be a problem, one is a transaction. We can skip it for the moment. Then, the database is frequently closed on this page.

In this case, the connection method of a page is described as follows: Isession vsession = Mcfg. buildsessionfactory (). opensession (); // To create a session factory, a singleton object should be used to encapsulate the session factory.

Itransaction vtransaction = Vsession. begintransaction (); // Create Transaction Processing

Try

{

Business Logic object. Operation (vsession)
Vtransaction. Commit ();

Labmessage. Text="OK";

}

Catch (Exception ex)

{

Vtransaction. rollback ();

Labmessage. Text="Error"+Ex. tostring ();

}

Finally

{

Vsession. Close ();

}

This code is written on the page.

So, this is what it looks like. After the operation is completed in the business logic, the database connection will be closed and the transaction will be committed when no database operation is required in the future.
I don't know how many people understand it.

Write it here, wait for the prawns to make bricks, and there is such a code if there is a thread problem. Should the page_load method be used to handle thread security issues? I don't know the efficiency problem. Is it because the database is closed frequently? It doesn't matter if you don't care about this overhead. If you make concessions for a clear structure, I have no objection, but this indicator should be taken into account when optimizing efficiency.
Many people say in the previous post that this would mean that I would die very ugly, but I don't understand it. Are there other methods that will not die very ugly?

Connection http://www.cnblogs.com/Alexander-Lee/archive/2007/03/31/694847.html for previous post