ejb3 任务队列大家有什么建议？

bfox

目前公司的系统是用的ejb3,  之前的老设计是接收到请求后不马上处理，而是保存到数据库中， 然后用timmer 驱动stateless session bean 来挨个处理。

这个设计很明显有问题， 当压力一大， 系统就会创建多个 session bean 的实例， 这样会导致多个session bean 处理同一个请求。

我觉得这个应该是message bean 的典型应用场景，但是公司领导处于种种考虑不愿意用message bean. 想请教下大家有没有什么message bean 之外的建议呢， 如果保存在数据库中， 怎么保证每个任务之被处理一次呢？

关键ejb 没有一个默认的singleton 的实现：（

飞翔翼

"当压力一大， 系统就会创建多个 session bean 的实例， 这样会导致多个session bean 处理同一个请求" 这句没明白，如果出现这种情况，只有可能是程序写的有问题，和是否使用数据库没有关系

dalaohu

我想lz说的是 multi-threading  和 message queue 的问题。

你在queue process 的逻辑里不能价格 unique check 吗？

rumcoke

我也跟ls想法类似, 如果并发非常频繁 还不如每次检查该任务是否在执行中
另外 如果考虑使用单态也可以自己写一个呀 并不复杂 只是私有化constructor而已 但是这和检查任务执行状态是2种结果 如果是简单的使用单态只能说同一时间只有一个任务被执行 那么性能不是更差了 除非加入判断 每个任务只能由一个单态实例执行 这其实又回到了检查任务执行状态去了

kawara

同意二楼，跟设计没关系，代码没写好。

3laugh

You may configure the pool size of the EJB to manage the load. If you set the max-size of the pool is 1 if you like (that’s bad), but that’s not singleton, a new instance may be created if the old one has died.

Definitely only one instance of the session bean is created for a request.  I believe it's more like a code issue  ->more likely, in the database transaction management ->more likely, in the way how you mark the record has been processed.

starchu

应该是多线程问题，导致相同请求被多次调用。 设计也是很有问题，明显想要进行异步消息出来，既然用EJB又不用其特定的message bean来处理异步消息，自己给自己添乱。 JEE设计里面最危险的就是把各种component用在了错误的地方，这样产生的效率问题对系统影响非常大，所以很多人常说java慢，特别是JEE做的系统慢，其实是系统设计和实现的问题，而不是语言和框架的问题。

bfox

原帖由 飞翔翼 于 2011-5-30 22:12 发表
"当压力一大， 系统就会创建多个 session bean 的实例， 这样会导致多个session bean 处理同一个请求" 这句没明白，如果出现这种情况，只有可能是程序写的有问题，和是否使用数据库没有关系

session bean 是用来接收请求，创建任务并放到数据库中。 同时有processor 用来从数据库中读取任务。 问题是processor 是放在session bean 里面的， timmer trigger的时候就会创建一个新processor，所以如果有多个timmer 就会有多个processor. 所以还是设计问题。

原帖由 dalaohu 于 2011-5-30 22:16 发表
我想lz说的是 multi-threading  和 message queue 的问题。

你在queue process 的逻辑里不能价格 unique check 吗？

message queue 就没有multi-threading 的问题了， 现在是原来的设计搞了个自己的task queue, 结果画虎不成。 应该能加check的，问题是以前的设计根本没考虑multi-threading ，有很严重的问题。

原帖由 rumcoke 于 2011-5-31 09:03 发表
我也跟ls想法类似, 如果并发非常频繁 还不如每次检查该任务是否在执行中
另外 如果考虑使用单态也可以自己写一个呀 并不复杂 只是私有化constructor而已 但是这和检查任务执行状态是2种结果 如果是简单的使用单态只能说同一时间只有一个任务被执行 那么性能不是更差了 除非加入判断 每个任务只能由一个单态实例执行 这其实又回到了检查任务执行状态去了

谢谢建议，我同意你的观点， 最好的办法还是在取任务的时候想办法保证唯一。

原帖由 kawara 于 2011-5-31 09:05 发表
同意二楼，跟设计没关系，代码没写好。

还是设计问题：）

原帖由 3laugh 于 2011-5-31 09:28 发表
You may configure the pool size of the EJB to manage the load. If you set the max-size of the pool is 1 if you like (that’s bad), but that’s not singleton, a new instance may be created if the old o ...

Very usefull hints. Seems this is the only solution to make the system WORK for buy me sometime to remake the design

原帖由 starchu 于 2011-5-31 09:46 发表
应该是多线程问题，导致相同请求被多次调用。 设计也是很有问题，明显想要进行异步消息出来，既然用EJB又不用其特定的message bean来处理异步消息，自己给自己添乱。 JEE设计里面最危险的就是把各种component用在了错误的地方，这样产生的效率问题对系统影响非常大，所以很多人常说java慢，特别是JEE做的系统慢，其实是系统设计和实现的问题，而不是语言和框架的问题。

就是多线程的问题。 原来的设计根本没有考虑同一个session bean 多个实例的情况。 sign



谢谢楼上几位tz的意见， 仔细想了想如果不用message queen的话，应该就是修改任务队列的设计，保证一个任务只被取一次的问题了。 还是争取改成用message 异步，只是这样一来就是个大改动了。

[ 本帖最后由 bfox 于 2011-6-1 17:31 编辑 ]

dalaohu

原帖由 bfox 于 2011-6-1 17:17 发表
message queue 就没有multi-threading 的问题了， 现在是原来的设计搞了个自己的task queue, 结果画虎不成。 应该能加check的，问题是以前的设计根本没考虑multi-threading ，有很严重的问题。

post process 加check　logic
pre　process　multi threading 下　要加lock。　注意死锁。

zn7726

大老虎是做J2EE的?

dalaohu

原帖由 zn7726 于 2011-6-1 17:44 发表
大老虎是做J2EE的?

哈哈，我连J２EE得全称是啥都不知道。

不过理念都是一样得。

zxinfhs

1. Ejb 环境不要考虑什么多线程问题，app_container 会创建ejb池管理这些ejb实例
2. 接受请求并插入数据库的session bean 在并发时会创建多个实例，但它是短事物，不会有任何问题
3. 原设计没啥问题，timer触发一个session bean 后（另一个session bean），在session bean 中挨个处理数据库中的任务，只需要一个session bean, 不需要多个session bean 实例

bfox

原帖由 zxinfhs 于 2011-6-1 18:20 发表
1. Ejb 环境不要考虑什么多线程问题，app_container 会创建ejb池管理这些ejb实例
2. 接受请求并插入数据库的session bean 在并发时会创建多个实例，但它是短事物，不会有任何问题
3. 原设计没啥问题，timer触发一个session b ...

1. 完全同意
2. 完全同意
3. 问题在这里， 原设计中把timmer放在接受请求并插入数据库中的session bean 上， 这样就导致了多个session bean 的实例都会被timmer trigger。 所以治本的解决办法只能是在读取任务的时候加上任务在处理中的标识。

数学家

原帖由 bfox 于 2011-5-30 21:12 发表

关键ejb 没有一个默认的singleton 的实现：（

记得EJB里可以定义最多有多少个EJB bean。但可能与EJB的Implementation有关。下面的例子是在Weblogic上的configuration，算是singleton的变相实现吧：

        <pool>
          <max-beans-in-free-pool>1</max-beans-in-free-pool>
          <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
        </pool>

rumcoke

原帖由 数学家 于 2011-6-2 11:17 发表


记得EJB里可以定义最多有多少个EJB bean。但可能与EJB的Implementation有关。下面的例子是在Weblogic上的configuration，算是singleton的变相实现吧：

        
          1
          1
         

我可能还没完全理解楼主的上下文 我觉得同时可以有多个session bean在活动 但是他们一定不能访问相同的任务 换句话说 session bean可以从同一个class里new出来 但是他们做的事情必须是相互unique的 不知道是不是了楼主的要求 那么pool的设置不见得直接解决问题 还是要保证一个任务同时只有1个bean在处理

数学家

原帖由 rumcoke 于 2011-6-2 13:20 发表

我可能还没完全理解楼主的上下文 我觉得同时可以有多个session bean在活动 但是他们一定不能访问相同的任务 换句话说 session bean可以从同一个class里new出来 但是他们做的事情必须是相互unique的 不知道是不是了楼主的要求 那么pool的设置不见得直接解决问题 还是要保证一个任务同时只有1个bean在处理

如果你的理解是正确的，那LZ的问题其实就跟EJB没什么关系了。他的问题是“要保证一个任务同时只有1个bean在处理”。

用个static的map做synchronizer效果还不错（一个任务被执行前，在map里注册），但不适用于多服务器。对于多服务器，用数据库的比较多，但效果不好（数据库的update时间相对太长，即使加lock也不是很安全）。

我个人在这方面没有太多经验，我一般都会用jms。

zxinfhs

不太理解你们这个设计
你有两种session bean， 一个做insert任务，多实例，用客户端请求触发，一个处理任务，用timer触发，单一实例,bean1 和bean2是完全无关的两个bean
既然用timer触发bean2，bean2的运行就只与时间间隔有关，与客户端请求无关
只有一种情况要注意，就是任务太多，一个时间间隔内处理不完，timer又触发了下一个bean2，造成问题，不过这个很容易处理

你说的那个用请求触发bean1, bean1内部触发timer，timer再触发bean2的方案我没理解错的话，其实是要实现延迟执行，根本就不是server side timer

[ 本帖最后由 zxinfhs 于 2011-6-2 19:40 编辑 ]

数学家

原帖由 zxinfhs 于 2011-6-2 19:34 发表
只有一种情况要注意，就是任务太多，一个时间间隔内处理不完，timer又触发了下一个bean2，造成问题，不过这个很容易处理

能详细说说怎么处理吗？这个问题困扰了我们很长时间，后来改成jms了。

zxinfhs

很多办法呀
比如：
1 - 数据库任务表加字段status = { new，pending，finish}
2 - timer触发bean2后，先检查是否有pending的任务，如果有，说明另一个憨豆正在工作，不打扰了，退出，如果没有，update table set status=pending where status == new，然后一个一个的处理任务，处理完一个，跟新一个状态，update status=finish where id = XXX
3 - 处理期间bean1新插入的任务，status为new，不影响当前工作
4 -处理期间如果timer触发了另一个bean2，根据逻辑2，新bean2会退出，保证只有一个bean2工作
5.bean2结束处理后，如果勤快一些，可以再看看是不是又有status==new的任务了，有就接着干，或者选择直接退出，让下一班的bean2做
不管如何，这个流程保证了只有一个bean2实例在处理任务

dalaohu

java　里是这样处理多线程得？？？　看得我都傻了。。。

２个bean　同时　被触发，此时没有pending任务呢？

zxinfhs

这个是ejb环境，不是普通的独立程序，用多线程加同步什么的
ejb脱胎于当年的corba方案，目的在于为developer提供一套标准，方便，可靠的并发环境，使developer只关注业务，不操心那些基础问题
corba很强大，强大到没有很好的商业产品实现其所有服务，ejb简化了corba，提供8个最重要的服务，包括生存期管理，分布式事务，异步消息等
ejb环境中，developer是不用自己new实例的，app container 替你搞定多线程，包括集群环境下的多进程，同步等等，而且不同app container处理方式不同，developer在ejb中写多线程是自找麻烦，还很容易出问题
现在的WCF也是采用同样的机制

- ２个bean　同时　被触发，此时没有pending任务呢？
bean1和bean2同时触发无所谓，不可能两个bean2同时触发，一定有时间间隔
bean2被触发后，如果没有pending，说明就你一人工作，搜索new的任务，有就处理，没有就退出呗

linkspeed

弱弱的问一句，这个EJB有必要用吗？不能用web service代替？
我一直想不明白这个问题。

njskater

不用message driven bean是出于什么考虑阿

dalaohu

wcf 里当然有多线程。ConcurrencyMode　可以直接设在servicebehavior上。当然你可以把他设为单线程得，但我们不讨论这个。　多线成得service里每个service　instance　entpoint都可以挂再message queue上。

再多线程里当然会发生　“同时”　得情况，concurrency就是这么来得。

你说得写多线程是自找麻烦，我不同意。　多线程能最大程度得利用硬件资源，responsiveness, scalbility都好很多。

而且，退一步讲，即时service本身不存在多线程得情况，也完全存在２个instance同时access　IO资源，　ie。　files, db。　所以我不太清楚。

像你说得ejb　有内置request　queue，单线程得话，设想每个request都是long　running，10分钟比方说，那排在后面得request可能要等上几个小时了。　我不知道这个你说得强大性体现再那里？

数学家

原帖由 zxinfhs 于 2011-6-3 19:51 发表
- ２个bean　同时　被触发，此时没有pending任务呢？
bean1和bean2同时触发无所谓，不可能两个bean2同时触发，一定有时间间隔
bean2被触发后，如果没有pending，说明就你一人工作，搜索new的任务，有就处理，没有就退出呗.

我觉得你用单个bean是为了简化设计。在做一些小项目的时候，这种简化设计还是可行的。在做大项目的时候，这个就不合适了，单个processor的顺序处理可能会造成任务堵塞，在资源利用也很浪费。而且用数据库做同步也是很不安全的 - 数据库在做大量数据更新的时候，所需时间可能就会较长。下一个bean来的时候，不能保证任务的status已经更新。我估计LZ说的压力测试出问题也由这方面的原因。

据我所知，现在大多数自编多线程都是由jms实现，因为管理起来比较方便。有些framework或commercial product也可以做到在timer上做同步（第一个timer触发的任务没有完成之前，下一个不触发，比如webMethods）。

特别要说一下，因为EJB比较heavy，而且EJB兼容的应用服务器都比较贵（JBoss是例外），很多人不喜欢用。所以有些framework提供了MDB的实现，比如用Spring里的jms/mdb就可以不在EJB的container里运行，这样会省很多money，呵呵。

[ 本帖最后由 数学家 于 2011-6-4 19:15 编辑 ]

zxinfhs

我说的这个方案是回应楼主的问题，就是用来处理小问题的，对于重负载的系统，按照J2EE的规范做法，还是要用JMS做的。
而且对于重载的核心系统，从性能和可靠性出发，一定要运行在集群环境，至少要保证双机，EJB为developer提供了最简便的实现手段，单机上的小timer显然是无法胜任的，还得jms上

zxinfhs

我不是说ejb就不用多线程，而是说开发ejb时，developer不要自己写多线程，要遵循J2EE的规范，把bean的生存期管理委托给app container 去做，由他去实现多线程和同步
实际上，j2ee的运行环境就是多线程，只不过它是由app container实现的，不是develper自己实现的罢了
j2ee的目标是企业级运算，可不仅仅是一个多线程这么简单。典型的ejb是运行在集群环境，系统实现负载均衡和节点之间的同步，支持跨区域和跨数据库的声明式事务等等，这些都是一个企业级系统不可或缺的功能

bfox

原帖由 zxinfhs 于 2011-6-2 19:34 发表
不太理解你们这个设计
你有两种session bean， 一个做insert任务，多实例，用客户端请求触发，一个处理任务，用timer触发，单一实例,bean1 和bean2是完全无关的两个bean
既然用timer触发bean2，bean2的运行就只与时间间隔有关，与客 ...

我也不理解这个设计， 你说的bean 1, bean2 在现在的设计里是一个bean. 实在是服了他们之前的人了。确实也是延时处理。

strongchina

根据我的经验，给你一个简单方案（我所在的项目用的：））
OPTION 1安全，效率低)
TIMER用STATEFUL JOB,简单讲确保一个JOB运行,这样你不用动其他

OPTION 2：
在保存时，对任务分组。这样你可以跑多个JOB，每个JOB分别处理对应组的数据。

我提供的方案是基于我们现有应用和环境提供的 绝对满足大数据量和集群应用的需要，而且简单。

我们是讲STATEFUL SESSION BEAN和Quartz实现的STATEFULE JOB