java通过jdbc thin方式连接数据库后，对数据库操作时会出现以下两种情况，我这可能记录不全：
1.在sqlplus中查询得到和java终端中输出的查询结果不同
2.执行某些sql语句卡住不动
这些情况只需要在sqlplus中执行 SQL>commit; 就可以完美解决
SQL> commit; 提交完成。
原文链接：http://blog.csdn.net/hzhsan/article/details/9719307
解释了执行executeUpdate语句卡住不动的原因：http://blog.csdn.net/tony_bupt/article/details/9144801
----------------------------------------------------转载的内容：
它执行的时候，你不会有什么感觉。commit在数据库编程的时候很常用，当你执行DML操作时，数据库并不会立刻修改表中数据，这时你需要commit，数据库中的数据就立刻修改了，如果在没有commit之前，就算你把整个表中数据都删了，如果rollback的话，数据依然能够还原。听我这么说，你或许感觉commit没什么用，其实不然。当你同时执行两条或两条以上的sql语句时，问题就出现了。举一个例子，你去银行转账，你转的时候银行的数据库会update你银行账户里面的数据，同时对另一个人得账户也进行update操作。这两个程序都必须全部正确执行，才能commit，否则rollback。如果只是完成一条，要么你郁闷，要么银行郁闷，第一种情况是，你的账户的钱没少，转账人得账户上的钱多了，银行郁闷了。第二种情况你的银行账户的钱少了，他的却没多，你就好郁闷了。Oracle好好学吧！sql不难，plsql努努力也能熬过去，等到优化那，哎！DBA不是那么好当的。还有就是commit算是显式提交，还有隐式提交，并不是，不commit的话，你的全部努力就都白费了。
这个命令是将数据写到数据库中。如果不执行COMMIT这个命令，那么在你这个session之外的其他session查询的数据是你修改数据之前的数据。而COMMIT之后人家查询的是你修改的数据。你可以打开两个sqlplus比较做一下测试。一目了然。
commit的提交针对的是:DML
Data Manipulation Language(DML) 需要提交，这部分是对数据管理操作，比如Insert（插入）、Update（修改）、Delete（删除）， Data Definition Language(DDL) 不需要提交，这部分是对数据结构定义，比如 Create（创建）、Alter（修改)、Drop（删除）
oracle的commit就是提交数据（这里是释放锁不是锁表），在未提交前你前面的操作更新的都是内存，没有更新到物理文件中。执行commit从用户角度讲就是更新到物理文件了，事实上commit时还没有写date file，而是记录了redo log file，要从内存写到data物理文件，需要触发检查点，由DBWR这个后台进程来写，这里内容有点多的，如果不深究的话你就理解成commit即为从内存更新到物理文件。锁有很多种，一般我们关注的都是DML操作产生的，比如insert，delete，update，select...for update都会同时触发表级锁和行级锁 补充：对的，insert以后commit之前是锁表的状态，其他事务无法对该表进行操作。
如果不提交的话，那么这个表就被锁了
COMMIT通常是一个非常快的操作，而不论事务大小如何。你可能认为，一个事务越大(换句话说，它影响的数据越多)，COMMIT需要的时间就越长。不是这样的。不论事务有多大，COMMIT的响应时间一般都很“平”(flat，可以理解为无高低变化)。这是因为COMMIT并没有太多的工作去做，不过它所做的确实至关重要。
这一点很重要，之所以要了解并掌握这个事实，原因之一是：这样你就能心无芥蒂地让事务有足够的大小。一种错误的信念认为分批提交可以节省稀有的系统资源，而实际上这只是增加了资源的使用。如果只在必要时才提交(即逻辑工作单元结束时)，不仅能提高性能，还能减少对共享资源的竞争(日志文件、各种内部闩等)。
分批提交COMMIT的开销存在两个因素：
显然会增加与数据库的往返通信。如果每个记录都提交，生成的往返通信量就会大得多。
每次提交时，必须等待redo写至磁盘。这会导致“等待”。在这种情况下，等待称为“日志文件同步”(log file sync)。
为什么COMMIT的响应时间相当“平”，而不论事务大小呢？在数据库中执行COMMIT之前，困难的工作都已经做了。我们已经修改了数据库中的数据，所以99.9%的工作都已经完成。例如，已经发生了以下操作：
已经在SGA中生成了undo块。
已经在SGA中生成了已修改数据块。
已经在SGA中生成了对于前两项的缓存redo。
取决于前三项的大小，以及这些工作花费的时间，前面的每个数据(或某些数据)可能已经刷新输出到磁盘。
已经得到了所需的全部锁。
执行COMMIT时，余下的工作只是：
为事务生成一个SCN。如果你还不熟悉SCN，起码要知道，SCN是Oracle使用的一种简单的计时机制，用于保证事务的顺序，并支持失败恢复。SCN 还用于保证数据库中的读一致性和检查点。可以把SCN看作一个钟摆，每次有人COMMIT时，SCN都会增1.
LGWR将所有余下的缓存重做日志条目写到磁盘，并把SCN记录到在线重做日志文件中。这一步就是真正的COMMIT。如果出现了这一步，即已经提交。事务条目会从V$TRANSACTION中“删除”，这说明我们已经提交。
V$LOCK中记录这我们的会话持有的锁，这些所都将被释放，而排队等待这些锁的每一个人都会被唤醒，可以继续完成他们的工作。
如果事务修改的某些块还在缓冲区缓存中，则会以一种快速的模式访问并“清理”。块清除(Block cleanout)是指清除存储在数据库块首部的与锁相关的信息。实质上讲，我们在清除块上的事务信息，这样下一个访问这个块的人就不用再这么做了。我们采用一种无需生成重做日志信息的方式来完成块清除，这样可以省去以后的大量工作(在下面的“块清除”一节中将更全面地讨论这个问题)。
可以看到，处理COMMIT所要做的工作很少。其中耗时最长的操作要算LGWR执行的活动(一般是这样)，因为这些磁盘写是物理磁盘I/O。不过，这里LGWR花费的时间并不会太多，之所以能大幅减少这个操作的时间，原因是LGWR一直在以连续的方式刷新输出重做日志缓冲区的内容。在你工作期间，LGWR并非缓存这你做的所有工作;实际上，随着你的工作的进行，LGWR会在后台增量式地刷新输出重做日志缓冲区的内容。这样做是为了避免COMMIT等待很长时间来一次性刷新输出所有的redo。
因此，即使我们有一个长时间运行的事务，但在提交之前，它生成的许多缓存重做日志已经刷新输出到磁盘了(而不是全部等到提交时才刷新输出)。这也有不好的一面，COMMIT时，我们必须等待，直到尚未写出的所有缓存redo都已经安全写到磁盘上才行。也就是说，对LGWR的调用是一个同步(synchronous)调用。尽管LGWR本身可以使用异步I/O并行地写至日志文件，但是我们的事务会一直等待LGWR完成所有写操作，并收到数据都已在磁盘上的确认才会返回。
前面我提高过，由于某种原因，我们用的是一个Java程序而不是PL/SQL，这个原因就是 PL/SQL提供了提交时优化(commit-time optimization)。我说过，LGWR是一个同步调用，我们要等待它完成所有写操作。在Oracle 10g Release 1及以前版本中，除PL/SQL以外的所有编程语言都是如此。PL/SQL引擎不同，要认识到直到PL/SQL例程完成之前，客户并不知道这个PL /SQL例程中是否发生了COMMIT，所以PL/SQL引擎完成的是异步提交。它不会等待LGWR完成;相反，PL/SQL引擎会从COMMIT调用立即返回。不过，等到PL/SQL例程完成，我们从数据库返回客户时，PL/SQL例程则要等待LGWR完成所有尚未完成的COMMIT。因此，如果在PL /SQL中提交了100次，然后返回客户，会发现由于存在这种优化，你只会等待LGWR一次，而不是100次。这是不是说可以在PL/SQL中频繁地提交呢？这是一个很好或者不错的主意吗？不是，绝对不是，在PL/SQ;中频繁地提交与在其他语言中这样做同样糟糕。指导原则是，应该在逻辑工作单元完成时才提交，而不要在此之前草率地提交。
COMMIT是一个“响应时间很平”的操作，虽然不同的操作将生成不同大小的redo，即使大小相差很大或者说无论生成多少redo，但也并不会影响提交(COMMIT)的时间或者说提交所用的时间都基本相同。
转自：
http://zhidao.baidu.com/question/345732898.html
http://zhidao.baidu.com/question/446956119.html
http://zhidao.baidu.com/question/126448794.html
http://soft.chinabyte.com/database/75/12306575.shtml