Databases Reference
In-Depth Information
safest answer is “yes.” The administrator just cost your application a significant
performance optimization.
What that question really means is, “Does this component access multiple
data sources in a logical unit of work?” Obviously, some applications require dis-
tributed transactions, but many applications don't need the protection that dis-
tributed transactions provide or the overhead associated with them. Be sure to
communicate with your application server administrator if you don't want your
application to use the default transactional behavior of the application server.
See “Transaction Management,” page 21, for more information about per-
formance and transactions.
Executing SQL Statements
Use the guidelines in this section to help you select which JDBC objects and
methods will give you the best performance when executing SQL statements.
Using Stored Procedures
Database drivers can call stored procedures on the database using either of the
following methods:
Execute the procedure the same way as any other SQL statement. The data-
base parses the SQL statement, validates argument types, and converts argu-
ments into the correct data types.
Invoke a Remote Procedure Call (RPC) directly in the database. The data-
base skips the parsing and optimization that executing a SQL statement
requires.
Performance Tip
Call stored procedures by invoking an RPC with parameter markers for
arguments instead of using literal arguments. Because the database skips
the parsing and optimization required in executing the stored procedure
as a SQL statement, performance is significantly improved.
Remember that SQL is always sent to the database as a character string. For
example, consider the following stored procedure call, which passes a literal
argument to the stored procedure:
{call getCustName (12345)}
 
 
Search WWH ::




Custom Search