JMS一个实例的应用策略请教

导入大文件，至少上万行到十几万行数据，然后每行插入数据库（mysql），现在的程序瓶颈在于插入mysql的过程，并且当一个用户在导入文件时候，其他用户再导入将等待很长时间，直到前一个用户的任务做完为止改进的思路：1.讲每个文件的数据分成好几块，每块包含几百行数据，然后这个块作为一个消息存入到jms队列里2.jms在取消息的时候讲做一个判断，比如如果发现其他用户的消息数据，就同时处理新用户的数据，而不是像之前的只能等到前一个用户的数据全部导入后再下一个问题：应采用如何的策略和逻辑来实现这个需求？比如用户A正在导入1w行数据的时候，用户B也开始导入1w行，这时候用户C也开始导入1w行，然后系统同时开始处理A、B、C的数据，这样子的结果是，尽管和原来的逻辑相比用户A的速度慢了很多，但用户C的速度要快一点，因为不用等待A和B完成了他才能继续。。

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

导入大文件，至少上万行到十几万行数据，然后每行插入数据库（mysql）按照你所说，一个用户就要执行几万次到十几万次的insert，你怎么能指望它快。。大文件直接blob就可以了，读写在java端执行，这样其他用户都不影响。
java执行那么多insert也是慢的关键不在这里而是如何实现这个调度的算法。。
不考虑用户插入数据库操作因素，使用异步jms通信不就可以了（同步需要等待），用户通过jms请求导入，服务器收到请求后把文件分块送往jms，用户获取分块的文件进行数据导入
10万数据，预计几秒就应该结束了吧。
2个技术关键点
1） insert values (),(),() 这种insert你要注意使用，每个单独的insert 性能是很差的。
2）不要每个insert都提交，可以100个提交一次
第三， mysql 支持 load date infile 方式，你也要考虑。
正常思路的确是这样子，但现在其实要做到多用户支持比如用户A上有1个10万行数据，分成100块，正在做，用户B进来带了100行数据，用户B肯定不能等用户A的10万行全部做完才轮到他做。。如果单纯的把文件分块放到jms的队列里，对于多用户就需要等待的。。
为什么会出现A、B、C...用户来读取该文件呢？
你不是将这些数据插入到数据库的表中了吗？为什么A、B、C用户不去读取表中的数据呢？
jms只需要转送文件就可以了，可以注册监听器，当jms收到分块的文件时，回调监听器，把文件送给相关的用户，也就说用户是直接获得文件，而不是在jms上读取文件
不是A、B、C去读文件。。是A B C分别导入自己的文件，因为数据量大，所以如果按线性顺序的话，B要等A做完才导入。。C要等B做完。。如此类推
不能多线程传送吗？否则异步jms送受信有什么意义啊？
首先jms有同步和异步两种方式，
同步的话是request-respone模式，这样请求就会等待
异步的话是receive-send模式，请求不用等待
读文件这个过程是很快的。。慢的是插入数据库的操作现在多线程的就是插入数据库。。比如一个文件10万行，分成100块，每块也就是1000行数据，然后作为一个jms消息存到队列里，然后很多个监听器去拿这些消息插入数据库去问题我前面也说了，用户A传了一个20万的数据，分成100个jms消息，然后监听器去接收去插入数据库了，这个过程里用户B也传了一个100行的数据，因为数据量少只分成1个消息，但这时候监听器正在接收A的消息，所以要等A的100个全部才可以，这样子是不行的需要用户B的消息能和用户A的消息交错被监听器接收，这样子B就不用等很长时间了
你直接在监听器调用，那没办法的，不过按正常队列的逻辑，A一下子来了这么多任务在排队，B任务来了排在A任务之后，也是可以理解和接受的，除非想让B任务插队。
如果是这样，你可以让监听器把消息都送到一个队列，用个线程池执行队列中的任务，这个队列是可以插队的，如果有B任务来了，可以把B任务插队。
还有一种就是用多个队列，线程池依次从多个队列中取任务执行，对个队列分别对应多个客户的消息，即A消息发送到A队列，B消息发送到B队列，C消息发送到C队列，用个计数器，线程池第一次从A取任务，第二次从B取任务，第三次从C取任务，如果取不到任务，则依次再取下一个队列的任务。
多个队列不现实，如果一个用户一个队列，那么上百个上千个用户就太多了。。问题也基本解决。。把用户A、B、C等的消息拿出来后按照round robin算法调度，每次只拿一个用户的消息，详见看这里 http://topic.csdn.net/u/20110621/12/7918440e-c718-4721-8df8-5c839c00d1c4.html感谢以上各位