首先，表不读取数据，某些事物"必须从表1中读取数据并将其插入表2中. 此外，从表1读取的任何内容可能都不会锁定表1的全部，它可能会锁定某些记录，但不会锁定整个表. 在此处和

First of all a Table does not read data, some "thing" must read data from table 1 and insert it into table 2. Furthermore whatever is reading from table 1 is probably not locking all of table 1, it may lock some records, but not the whole table. Look here and here for information on how to find locks in Oracle. However:

更好的选择是在更高级别进行同步；您的Java代码和更新表2之间的任何关系.
可以使用适当的同步机制(信号量，互斥量，java锁等)基于更新表2的事物"以及所使用的平台来完成此操作.如果无法进行专门的同步，则可以在数据库本身中实现锁定.

A better option is to synchronize at a higher level; between your java code and whatever is updating Table 2.
This can be done using appropriate synchronization mechanisms (semaphores, mutexes, java locks, etc.) based on what the "thing" that updates table 2 is and what platform is being used. If specialized synchronization is not possible, you can implement the lock in the database itself.

(非常简单)的此类实现使用具有列owner和lockID的表lock.然后为每个参与者提供一个唯一的标识符，并使用以下SQL语句声明锁定:

A (very) simple such implementation uses a table lock with columns owner and lockID. Each participant is then given a unique identifier and uses the following SQL statements to claim the lock:

    update lock set owner = <my unique identifier> where owner is null and lockID = <lock id>

    select owner from lock where lockID = <lock id>

owner对应于成功领取了锁的参与者的唯一标识符. 要取消锁定，只需将其设置为null.

The owner corresponds to the unique identifier of the participant that successfully claimed the lock. To unclaim the lock simply set it to null.

虽然简单，但这种方法仍然会给您带来一个问题，即弄清楚何时释放锁，如果锁没有及时释放(或触摸)，会使锁陈旧，如果对锁的竞争激烈，则可能会饿死.

While simple, this approach still leaves you with the problem of figuring out when a lock becomes free, making a lock stale if it is not released (or touched) on time and possible starvation if the lock is highly contested.

如果您确实想实现近乎实时的性能，那么更好的选择是消除数据库.任何数据库的变量(缓存，维护后台线程，本地优化等)太多，无法实现一致的性能.一个旨在实现近实时性能的系统将必须使用针对特定平台量身定制的异步文件IO，并且可能需要使用非垃圾收集语言，以便可以控制内存分配和释放.

An even better option if you really want to achieve near real time performance is to eliminate the database. Any database has too many variables (caches, maintenance background threads, local optimizations, etc.) to achieve consistent performance. A system that aims at near real time performance would have to use asynchronous file IO tailored to the specific platform and would probably need to use a not garbage collected language so memory allocation and deallocation can be controlled.