ESQL 发生死锁时 sqlcode 不返回 DEADABORT
我试图了解如何使用 ESQL 管理死锁。我创建了 2 个并发进程，尝试更新“客户”表，与 O'Neil 的书“数据库”中给出的示例完全相同： pg=PA298&lpg=PA298&dq=%22deadabort%22+oracle&source=bl&ots=2QF7eSbaW6&sig=IcEZtSXINKrOVro1UN-ShlNsAak&hl=en&ei=9BPvTKPfMtP4nwfqu_X1Cg&sa=X&oi =book_result&ct=结果& ;resnum=1&ved=0CBcQ6AEwAA#v=onepage&q=%22deadabort%22%20oracle&f=false" rel="nofollow noreferrer">http://books.google.ca/books?id=UXh4qTpmO8QC&pg =PA298&lpg=PA298&dq=%22deadabort%22+oracle&source=bl&ots=2QF7eSbaW6&sig=IcEZtSXINKrOVro1UN-ShlNsAak&hl=en&ei=9BPvTKPfMtP4nwfqu_X1Cg&sa=X&oi= book_result&ct=结果& resnum=1&ved=0CBcQ6AEwAA#v=onepage&q=%22deadabort%22%20oracle&f=false
但是由于某种原因，等待 1 完成的进程 2 阻塞在语句“exec sql”处更新客户”，并且永远不会输入“if(sqlca.sqlcode == DEADABORT)”语句。因此，我永远无法解决僵局。
有人有想法吗？
I'm trying to understand how deadlocks can be managed using ESQL. I created 2 concurrent processes that try to update a "customers" table, exactly like the example given in O'Neil's book "Database": http://books.google.ca/books?id=UXh4qTpmO8QC&pg=PA298&lpg=PA298&dq=%22deadabort%22+oracle&source=bl&ots=2QF7eSbaW6&sig=IcEZtSXINKrOVro1UN-ShlNsAak&hl=en&ei=9BPvTKPfMtP4nwfqu_X1Cg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBcQ6AEwAA#v=onepage&q=%22deadabort%22%20oracle&f=false
But for some reason, the process 2 that is waiting for 1 to finish blocks at the statement "exec sql update customers", and never enters the "if(sqlca.sqlcode == DEADABORT)" statement. Hence, I can never manage the deadlock.
Does anybody have an idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果没有看到代码，就很难评论，但即使有两个连接，在单线程程序中也很难（如果不是不可能）产生数据库死锁错误。
在单线程程序中，
它尚未达到死锁条件，因为连接 A 只是在等待连接 B。数据库不知道这两个数据库连接都来自单个进程/线程，因此它不知道他们陷入僵局。
连接池有时会出现此问题。一个最终用户会话使用池中的连接锁定共享资源。其他池连接填满了该共享资源上的所有等待，然后该原始最终用户会话无法获得连接池线程来释放资源。
Without seeing the code it is hard to comment, but a database deadlock error is going to be very hard (if not impossible) to produce in a single threaded program even if you have two connections.
In a single threaded program
It hasn't reached the deadlock condition because Connection A is simply waiting on Connection B. The database doesn't know that both database connections are from a single process/thread so it doesn't know they are deadlocked.
This issue crops up with connection pools sometimes. One end user session locks a shared resource using a connection from the pool. The other pool connections fill up all waiting on that shared resource, and then that original end user session can't get a connection pool thread to release the resource.