Java实时获取oracle变更

你说的不错，我们也可以采用你说的这种方式
但有几点是和具体业务相关的
这个不仅仅是监控系统，还包括车辆巡逻，考勤签到等功能，甚至包括车辆出辖区告警等判断操作，必须保证前台显示和数据库存档的历史记录完全匹配，综合考虑后，选择基于数据库完成此功能。
不过这是和具体业务相关了，于我们本帖讨论的问题本身无关紧要，以GPS为例，只是拿我们实际案例说话，觉得更有说服力。

你不妨以我们这个案例中的另一个功能“车辆一旦离开某个范围即进行告警”来作为参考

兄弟,那就是说利用MS SQL Server2005中的反向通知,也能实现楼主所说的意思了,我试试去!

如果按照这种方案,while (true),这不是要让客户端与db长连接吗?如果客户端数千个,这种方法还有效吗?

个人认为,对于这种'实时数据反馈'的系统,还是考虑commit方式.有新数据,server主动通知client!

呵呵,目前我们也在做这方面的应用,希望能借这个地方,多与大家讨论,学习学习!

你说的对，但和我们这里讨论的是两个层面。你可以想象为“还是考虑comet方式.有新数据,server主动通知client”是下一步的工作，先考虑一下怎么知道有新数据。
我们这里可以只开一个单独线程来专门从队列里面获取数据，也可以使用MDB的方式，and so on……

SQLServer2005 Servie Broker

个人以为用stream捕捉Oracle的数据变化并产生实时并不是一个好方法。原因如下：
1.Oracle stream技术不成熟。stream的数据变化捕获，是通过log miner读取redo日志产生。一直到10g版本，log miner都存在缺陷，它不能捕捉所有的数据变化，如果你的源表的设计比较特殊，或者对该表的一些操作比较特别，那么你会看到一堆unsupported日志
2.既然它是从redo日志产生消息，那么它就不是实时的，而是异步的，而且延迟时间超过5秒甚至更多，这就达不到实时的目的

另外，实时消息，应该在经过新旧比较之后产生，不经过新旧比较就产生的消息，会有大量的数据冗余。比如对一个被订阅的表的某个在界面上不需要的列进行了一次批量更新，更新数据达到上万行。在理论上，是不需要产生实时的，实际上却不是如此。

再者，在界面上显示的数据，大多数不是直接来源于某个表，而是对一个或多个表的数据进行数据整理(例如通过联合视图或存储过程)后才显示，直接基于表来发送实时，意味着客户端或中间层可能还基于实时对数据库作重复查询。

个人以为在实时这块，用Oracle data change notification或Oracle cdc好些。

还是方案二好，所谓的就看你怎么定义数据采集系统了。采集系统对消息做出响应是很正常的。
数据库又凭什么知道前端系统的存在？？