Second, Connection Pooling:
The connection pool is such a mechanism. When the application turns off a connection, this connection is reclaimed, not by DESTROY, because establishing a connection is a very expensive operation. If you can reuse recycled connections, you will reduce the number of newly created connections, significantly improve the performance of the run.
Suppose the application needs to create a connection to a DataSource for Empolyeedb. The code to be connected using the connection pool is as follows:
CONTEXT CTX = New InitialContext (); DataSource DS = (DataSource) CTX.lookup ("JDBC / Employeedb"); Connection Con = DS.GetConnection ("MyPassword", "MyuserName"); In addition to the logical name, we discover its code The code of the example mentioned above is the same. Different logical names can be connected to different databases. Whether the Connection returned by the getConnection method of the DataSource object is a connection in a connection pool depends entirely on the implementation of the DataSource object. If the DataSource object is implemented with a server that supports the intermediate layer that supports the connection pool, the DataSource object will automatically return to the connection in the connection pool, which is also repeatedly utilized.
Whether to use the connection pool to get a connection, you can't see different on the code of the application. There is no different place to use this Connection connection, the only difference is to close a connection in the Java's Finally statement block. Close connection in Finally is a good program habit. In this way, even if the method throws an abnormality, the Connection is also closed and reclaimed into the connection pool. The code should look like this:
Try {...
} catch () {...
} finally {if (con! = null) Con. close ();
Third, distributed affairs:
Getting a connection to support distributed transactions is similar to those in the connection pool. Similarly, the difference is that DataSource is different, not what is different in the way in which the connection is obtained. Suppose the DataSource's implementation can work with the supporting transaction intermediate layer server, get the code is as follows:
CONTEXT CTX = New InitialContext (); DataSource DS = (Datasource) CTX.lookup ("JDBC / EMPLOYEEDB"); Connection Con = DS.GetConnection ("Mypassword", "MyuserName); due to performance, if a DataSource Can support distributed transactions, which can also support connection pool management.
From the point of view of the application designer. Whether to support distributed transactions is nothing different, the only difference is on the border of the transaction (where a transaction is started and the place to end a transaction), starting a business or ending a transaction is transaction server To control. Applications should not do anything that may hinder service. The application is not able to directly call the transaction Submit commit or rollback ROLLBACK operations, or you cannot use the Auto Submit mode of the transaction Auto-Commit Mode (automatically call your COMMIT or ROLLBACK) when the database operation is completed.
