This topic has been archived. It cannot be replied.
-
工作学习 / IT技术讨论 / 再问一个有关数据库和.net的connection pool问题。我现在需要处理大批量的数据，于是使用windows service timer，每1秒钟检测一次数据库，是否有需要处理的数据。如果有，就每次处理完一个纪录后，马上取出下一个需要处理的纪录。现在基本上是每秒钟处理5条纪录。
目前存在的问题是，处理完5万条左右的纪录后，就会出现下面的error message:
Cannot insert duplicate key row in object 'table1' with unique index 'INDEX_2'.
程序里面设置重试100次，这个问题仍然存在。
重新开始windows service，这条记录就可以被处理了。也就是说并非因为某条纪录的问题。
com+里面设置的是read committed。在别的系统里，也碰到过这个问题。但是如果不用connection pool，速度大大降低。
各位大虾，有没有遇到过这样的问题。谢谢指教。
-lilyba(sunshine);
2004-9-15
{470}
(#1887002@0)
-
I'd like to use store procedure to solve this problem.Still using the timer to trigger the Store procedure, which should be more suitable to handle this high volumn of processing, and save a lot time on the commit.(I'm not sure how did u perform the commit in you case)
-elac(elac);
2004-9-15
{216}
(#1887186@0)
-
thanks. but all sps have been optimized.
-lilyba(sunshine);
2004-9-15
(#1887506@0)
-
up
-lilyba(sunshine);
2004-9-15
(#1887677@0)
-
up
-lilyba(sunshine);
2004-9-16
(#1888640@0)
-
up
-lilyba(sunshine);
2004-9-17
(#1890308@0)
-
up
-lilyba(sunshine);
2004-9-17
(#1890626@0)
-
Not sure but have you tried to change the max pool size to a bigger one in your connection string?You may post the question to other forums, such as:
asp.net/forums, or newsgroup, such as microsoft.public.dotnet.framework.adonet , good luck.
-cloud2001(卷云溶月-FlyFlyAway);
2004-9-17
{144}
(#1890471@0)
-
Thanks. We are going to open a issue with microsoft guys.
-lilyba(sunshine);
2004-9-17
(#1890628@0)
-
可能的原因:重新开始windows service，这条记录就可以被处理了。也就是说并非因为某条纪录的问题。
------- 未必.
Cannot insert duplicate key row in object 'table1' with unique index 'INDEX_2'.
这一定是这个KEY的老记录没删除掉. 数据库在这种问题上不会出错的. 所以还是检查你自己的程序吧. 没删除掉的原因可能是某个transaction挂在那里没提交也没rollback. 重启service可能transaction就释放了.
程序里面设置重试100次，这个问题仍然存在。
transaction没提交, 试多少次都没用.
这个应该和Read的隔离度没有关系.
-oceanwater(灌水日月长);
2004-9-17
{496}
(#1890493@0)
-
我们用的是microsoft data application block，缺省设置是5个连接。现在的问题可能就是long transaction造成的。但是如何解决这个问题呢？
-lilyba(sunshine);
2004-9-17
(#1890837@0)
-
那就缩短transaction。那么长的transaction，设计本身就应该有问题。仔细想想那么长的transaction有没有必要。这个对数据库的性能影响是致命的
-oceanwater(灌水日月长);
2004-9-17
(#1890918@0)
-
长的transaction是必需的。我的问题是，为什么开始几万条记录的transaction都不会有问题，而后来就会有问题了呢
-lilyba(sunshine);
2004-9-17
(#1891026@0)
-
干脆用个triger 算了.
-ange0791(human);
2004-9-17
(#1890496@0)
-
Many business rules involved, which might need to change later, so we cannot just use trigger. :(
-lilyba(sunshine);
2004-9-17
(#1890630@0)
-
"我现在需要处理大批量的数据，于是使用windows service timer，每1秒钟检测一次数据库" 这句话好像有个bug.
-ange0791(human);
2004-9-17
(#1890515@0)
-
Every second check the database to see if there any new record need to be processed. If there is new record, then it will keep processing all records marked as new record until they are done.
-lilyba(sunshine);
2004-9-17
(#1890637@0)
-
我知道是什么问题了。问题就出在你每1秒种执行一次。如果你上一次的处理没有在一秒种之内返回，这是第二次调用开始了，就会出现两个作业同时处理同一条纪录。哈哈。。。。给你初个主意。你让你的每一次程序的结束时自动 submit itself to a single thread job queue. 不知道你的机器之不支持啊。
-aka(棒棒);
2004-9-17
{115}
(#1891322@0)
-
test
-bigdesk(It's skii time!);
2004-9-17
(#1891712@0)
-
not true. 如果windows timer调用的时候不是每次都创建一个新thread的华（从其描述看起来应该不是），每次执行的时候应该都是在主调线程李执行即都是顺序执行的，如果前一个调用没有完成，后一次调用是没有开始的，应该不存在同时两个线程处理同一条记录。应该再提供更多的信息便于分析原因。建议记录一些log来查看运行时的数据。
-bigdesk(It's skii time!);
2004-9-17
{173}
(#1891732@0)
-
Yes, this is reason why insert failed.
Fix method:
1. increase service loop timer, like 1 minutes
2. not get record one by one, use SP, or batch mode to deal with all record
-nohairmonk(无毛和尚);
2004-9-18
(#1891835@0)
-
你们的做法跟偶要做的几乎一模一样， 偶可以肯定自己的设想没错了。：）） //谢谢！
-henhen(亨亨 ^_*);
2004-9-17
(#1891733@0)
-
取决于你怎么处理这些记录，你是再循环里每次处理一条记录后就commit呢还是再整个循环后再commit?
-bigdesk(It's skii time!);
2004-9-17
(#1891744@0)
-
实际上是每次监测到有新的数据，就要disable timer, 直到所有标志为新的数据全部处理完，enable timer。目前的问题是，ms data application block有5个connection。是不是因为这个问题。
-lilyba(sunshine);
2004-9-17
(#1891770@0)
-
不知道你里面的具体实现, 不好说, 但5个连接已经很少了, 一般最大连接着几十个都正常. 你数据处理得很慢, 可以试着把最大连接数改成50试试看结果如何减少连接数无非就是让对数据库的访问序列化, 大家轮流访问. 这样也许能解决问题. 但既然要这样才能解决, 你何不在程序里这样做, 不必要在连接数上做文章
你提供的信息不足以做出判断, 大家都在猜测
-oceanwater(灌水日月长);
2004-9-18
{186}
(#1891863@0)
-
谢谢大虾。在server的event viewer里面就只是这一点信息。还需要别的什么信息呢。如果我disable connection pool，这个错误就没有了。但是速度太慢了。
-lilyba(sunshine);
2004-9-18
{530}
(#1891878@0)
-
这个错误信息没什么价值的. 我是说我不知道你的程序里在干什么. 我们原来的一个多线程服务器程序, 在2CPU服务器上每运行两天会出错,换到4CPU服务器上, 每两小时会出一次错. 这种错误只能看日志,仔细分析
-oceanwater(灌水日月长);
2004-9-18
(#1892553@0)
-
Your logic is only right when: check new records + disable the timer takes less than a secend and last process has commited.. ..... Which, in turn, depends on how many records are there in your tables......I would suggest
Only one program, with an endless loop.,,,,,,,,,,,,,,
do while 1=1;
Any_new_rec = check_this_table();
If Any_new_rec = 'Y';
do_my_stuff();
endif;
sleep (1);
enddo;
-aka(棒棒);
2004-9-18
{210}
(#1892487@0)
-
好象有点make sense。
-henhen(亨亨 ^_*);
2004-9-18
(#1892490@0)
-
是啊，我就是这么写的阿。就是在LOOP里面处理数据的时候出现的这个错误
-lilyba(sunshine);
2004-9-18
(#1892532@0)
-
告诉偶最后你怎么处理的。
-henhen(亨亨 ^_*);
2004-9-17
(#1891720@0)
-
not a problem. ：P
-lilyba(sunshine);
2004-9-18
(#1891817@0)
-
谢谢，偶觉得要处理的太相似了。
-henhen(亨亨 ^_*);
2004-9-18
(#1892451@0)
-
Why don't you use the db server deal with this directly. I mean...
-sellcar_2003_may(sellcar_2003_may);
2004-9-18
{611}
(#1891988@0)
-
Thanks. Actually i think you might not understand our situation. We are making a business engine, which must be flexible and whose businees rules can be changed in future.
-lilyba(sunshine);
2004-9-18
(#1892332@0)
-
Business tier can be encapsulated on db side or application side.
Actually...Actually if it's located on db side it's much easier (flexible) for you to change the business rule in the future because you don't have to compile and deploy your middle ware.
-sellcar_2003_may(sellcar_2003_may);
2004-9-20
{179}
(#1894128@0)