13518219792
数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。 加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。 在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。 根据保护的对象不同，Oracle数据库锁可以分为以下几大类： DML锁（data locks，数据锁），用于保护数据的完整性； DDL锁（dictionary locks，字典锁），用于保护数据库对象的结构，如表、索引等的结构定义； 内部锁和闩（internal locks and latches），保护数据库的内部结构，应用于SGA； 在我们实际应用开发中涉及较多的是DML锁，其他两种的话DBA会更加关心点； DML锁的目的在于保证并发情况下的数据完整性，主要包括TM锁和TX锁，其中TM锁称为表级锁，TX锁称为事务锁或行级锁。 当Oracle执行DML语句时，系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式，在数据库中用0－6来表示。不同的SQL操作产生不同类型的TM锁。如下图所示： 值 锁模式 锁描述 SQL 0 NONE 1 NULL 空 SELECT 2 SS(ROW-S) 行级共享锁 其他对象只能查询这些数据行 SELECT FOR UPDATE、LOCK FOR UPDATE、 LOCK ROW SHARE 3 SX(ROW-X) 行级排它锁 在提交前不允许做DML操作 INSERT、UPDATE、DELETE、 LOCK ROW SHARE 4 S(SHARE) 共享锁 CREATE INDEX、LOCK SHARE 5 SSX(S/ROW-X) 共享行级排它锁 LOCK SHARE ROW EXCLUSIVE 6 X(eXclusive) 排它锁 ALTER TABLE、DROP TABLE、DROP INDEX、 TRUNCATE TABLE、LOCK EXCLUSIVE 在数据行上只有X锁（排他锁）。在 Oracle数据库中，当一个事务首次发起一个DML语句时就获得一个TX锁，该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行 DML语句时，第一个会话在该条记录上加锁，其他的会话处于等待状态。当第一个会话提交后，TX锁被释放，其他会话才可以加锁。 在大概了解oracle的锁机制之后，我们来解决几个基本的问题： 1.UPDATE/DELETE操作会将RS锁定，直至操作被COMMIT或者ROLLBACK； 若操作未COMMIT之前其他session对同样的RS做变更操作，则操作会被hold，直至前session的UPDATE/DELETE操作被COMMIT； 2.session内外SELECT的RS范围 前提：INSERT、UPDATE操作未COMMIT之前进行SELECT； 若在同一session内，SELECT出来的RS会包括之前INSERT、UPDATE影响的记录； 若不在同一session内，SELECT出来的RS不会包括未被COMMIT的记录； 3.SELECT.... FOR UPDATE [OF cols] [NOWAIT/WAIT] [SKIP LOCKED] OF cols：只锁定指定字段所在表的RS，而没有指定的表则不会锁定，只会在多表联合查询时出现； NOWAIT：语句不会hold，而是直接返回错误ORA-0005
成都网络公司-成都网站建设公司创新互联公司10余年经验成就非凡，专业从事成都网站制作、网站设计、外贸网站建设，成都网页设计，成都网页制作，软文平台，1元广告等。10余年来已成功提供全面的成都网站建设方案，打造行业特色的成都网站建设案例，建站热线：13518219792，我们期待您的来电！
oracle使用语句savepoint sp_begintran开启显式事务，锁本身和事务是没有关系的，只要是数据库的操作都会产生锁。处于事务中的SQL语句只有这个事务提交（commit）之后，事务中的SQL语句影响的表记录上的锁才会释放。锁常见有共享锁（select语句产生）和排它锁（DML语句产生），如果一个表上加载有共享锁，还可以叠加共享锁，但不能叠加排它锁。如果一个表上加载有排他锁，就什么锁都不能加了，也就是说如果DML语句占用过多的时间，这些数据库效率就不高，就需要优化，当然select语句性能低了也不行。
每个存储过程可以不用显式事务，它本身就为你开启了一个隐式事务，如果需要开启显示事务，就通过savepoint sp_begintran开启，无论是不是显式还是隐式事务，你都得通过commit work提交事务，通过exception捕捉SQL语句异常，在异常发生时需要回滚事务（rollback work）。
你这个需求是不能够通过数据库的事务管理功能来进行实现的，因为数据库执行的是严格的ACID，提交了就确认持久化了，而不提交就不能够被其他的事务所访问，对于update操作来说，会申请排它锁，这时其他事务是无法访问该数据的，直到commit为止才能够访问。
我觉得你的需求本事就是破坏事务特性的（只部分满足ACID），这时要实现的话就只能从程序的级别来进行实现，就是在编程的时候实现功能，类似事务的控制要用程序来实现，比如更新的日志用缓存存在内存中或写到一个文件上
