事务是工作中的基本逻辑单位。数据库的主要责任是保存信息，因此它需要向用户提供保存当前程序状态的方法。同样，当事务执行过程中发生错误时，需要有一种方法使数据库忽略当前的状态，并回到前面保存的程序状态。这两种情况在数据库用语中分别称为提交事务和回滚事务。为了处理这两种情况，JDBC API 包括了两个方法commit()和rollback()，分别用于实现事务的提交和回滚。在使用这两个方法时通常要使用try ... catch语句捕获数据库实际运行操作时可能发生的SQLException。
当多个用户访问相同的数据时，可能会出现3种问题：
脏读如果一个应用程序使用了被另一个应用程序修改过的数据，而这个数据处于未提交状态，这时就会发生脏读。第二个应用程序随后会请求回滚被其修改的数据，从而导致第一个事务使用的数据被损坏，即所谓"变脏"。
不可重复的读如果一个事务获得了数据，而该数据随后被另一个事务所更改，那么第一个事务再次读取更改后的数据，就会发生不可重复的读。
虚读如果一个事务通过某种查询获取了数据，另一个事务修改了该数据的一部分，那么原来的事务第二次获取该数据时，就会发生虚读。
为了解决这些由于多个用户请求相同数据而引起的问题，事务之间必须用锁相互隔开。多数主流的数据库支持不同类型的锁；因此，JDBC API支持不同类型的事务，它们由 Connection对象的setTransactionLevel方法指定。在JDBC API中可以获得下列事务级别：
TRANSACTION_NONE 说明不支持事务。
TRANSACTION_READ_UNCOMMITTED 说明一个事务在提交前其变化对于其他事务来说是可见的。这样脏读、不可重复的读和虚读都是允许的。
TRANSACTION_READ_COMMITTED 说明读取未提交的数据是不允许的。这个级别仍然允许不可重复的读和虚读产生。
TRANSACTION_REPEATABLE_READ 说明事务保证能够再次读取相同的数据而不会失败，但虚读仍然会出现。
TRANSACTION_SERIALIZABLE 是最高的事务级别，它防止脏读、不可重复的读和虚读。
运行在TRANSACTION_SERIALIZABLE模式下的事务可以保证最高程度的数据完整性，但事务保护的级别越高，性能损失就越大。
假设我们现在有一个Connection对象con，那么设置事务级别的方法如下：
con.setTransactionLevel(TRANSACTION_SERIALIZABLE) ;
你也可以使用getTransactionLevel()方法来获取当前事务的级别：
con.getTransactionLevel();
在默认情况下，JDBC驱动程序运行在"自动提交"模式下，即发送到数据库的所有命令运行在它们自己的事务中。这样做虽然方便，但付出的代价是程序运行时的开销比较大。我们可以利用批处理操作减小这种开销，因为在一次批处理操作中可以执行多个数据库更新操作。但批处理操作要求事务不能处于自动提交模式下。为此，我们首先要禁用自动提交模式。
executeBatch()方法返回一个更新计数的数组，每个值对应于批处理操作中的一个命令。批处理操作可能会抛出一个类型为BatchUpdateException的异常，这个异常表明批处理操作中至少有一条命令失败了。(T111)