删除记录时出现问题
我有一个实体管理器 em1 .em1 在 db1 table1 上启动交易 tx。现在在 tx 内我调用 API getdata()。该 API 创建一个新的实体管理器 em2 并返回 1 条记录。现在，如果实体管理器 em1 尝试删除返回的记录到em1时，它挂起。代码超时。记录是否被em1锁定。ii如何解决这个问题？
create em1
//em1 start transcation tx1
tx1.start
Object r = getData();
em1 tried to delete r //code hangs here
tx1.commit
Object getData(){
create em2
return data found using em2
}
I have a entity manager em1 .em1 starts a transcation tx on db1 table1.Now inside tx i call a API getdata().This API creastes a new entitymanger em2 and return 1 record.Now if entity manger em1 tries to delete the record returned by em1 , it hangs.Code times out.Is the record locked by em1.How can ii solve this problem?
create em1
//em1 start transcation tx1
tx1.start
Object r = getData();
em1 tried to delete r //code hangs here
tx1.commit
Object getData(){
create em2
return data found using em2
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不要创建 em2。将 em1 作为参数传递给
getData()方法。这样做，您只操作一个 em1。我不太清楚，但 em1 似乎在相关表上加了锁，所以你不能在外面做任何事情。
Don't create an em2. Pass the em1 as a parameter to
getData()method. Doing so, you're operating only one em1.I don't know exactly, but it seems that em1 is putting lock on the related table, so you can't do anything outside.
从你的问题中并不清楚EM2的记录是否与EM1涉及的表有任何关系。如果是这样，那么可能是因为 EM2 没有关闭。请注意，即使“选择”事件也涉及事务。所以，我想说，第一件事是在 EM2 中添加显式事务划分。隐式事务并不是一件好事，根据您所使用的数据库和隔离级别，底层数据库可能正在等待 EM2 的隐式事务完成，从而导致代码中出现死锁。
我的建议：
作为一个好的实践，尝试始终显式地开始和提交事务，即使是为了阅读目的。请记住，即使您没有指定事务，您的数据库也将隐式启动一个事务。
It's not clear from your question whether EM2's record have anything to do with the tables involved in EM1. If so, then it may be because EM2 wasn't closed. Note that even "select" events involves transactions. So, I would say that the first thing would be to add explicit transactions demarcation in EM2. Implicit transactions are not really a good thing, and depending on the database and isolation levels you are using, the underlying database may be waiting for the EM2's implicit transaction to finish, causing a dead lock in your code.
My suggestion:
As a good practice, try to always explicitly begin and commit a transaction, even for reading purposes. Remember that even if you don't specify a transaction, your database will start one implicitly.