Java Reference
In-Depth Information
Table 11-1. Seconds required to insert data for 128 stocks
Programming mode
Time required
DB calls DB commits
Autocommit enabled, no batching 2220.53 seconds 200,448 200,448
1 commit for each stock
174.44 seconds 200,448 128
1 commit for all data
169.34 seconds 200,448 1
1 batch per commit for each stock 19.32 seconds
128
128
1 batch per stock; 1 commit
17.33 seconds
128
1
1 batch/commit for all data
11.55 seconds
1
1
Note one interesting fact about this table that is not immediately obvious: the difference
between lines 1 and 2 is that autocommit has been turned off and the code is explicitly call-
ing the commit() method at the end of each while loop. The difference between lines 1 and
4 is that statements are being batched—but autocommit is still enabled. A batch is con-
sidered one transaction, which is why there is a one-to-one correspondence between database
calls and commits. In this example, then, a larger benefit accrued from batching than from
explicitly managing the transaction boundaries.
Transaction isolation and locking
The second factor affecting transaction performance concerns the scalability of the database
as data within transactions is locked. Locking protects data integrity; in database terms, it al-
lows one transaction to be isolated from other transactions. JDBC and JPA support the four
major transaction isolation modes of databases, though they differ in the way they accom-
plish that.
Isolation modes are briefly covered here, though since programming to a correct isolation
mode isn't really a Java-specific issue, you are urged to consult a database programming
topic for more information.
The basic transaction isolation modes (in order from most to least expensive) are:
TRANSACTION_SERIALIZABLE
This is the most expensive transaction mode; it requires that all data accessed within the
transaction be locked for the duration of the transaction. This applies both to data ac-
Search WWH ::




Custom Search