Menu
▾
▴
[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1739) HILO id can cause deadlock: Part deux
|
From: Bruce A. (JIRA) <no...@at...> - 2006-06-06 18:32:38
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739?page=comments#action_23279 ] Bruce Atherton commented on HHH-1739: ------------------------------------- Thanks for opening this issue, Kirk. Since I've had no luck convincing the powers that be to reopen HB-1246, perhaps we can move forward with this one. It sounds like there are at least two situations that can expose this deadlock: having more threads than database connections, and having deep object graphs. I think that both situations are resolved if it is possible to configure hibernate to use a separate data source for id generation. I've started down this path in the code, and it seems eminently doable. If the reason the issue isn't being addressed is the need for a patch, let me know and I'll finish adding the feature and generate one. I don't want to go to the effort, though, if it is just going to be ignored. So my question is, do the hibernate developers agree in principle with the idea of allowing for a separate data source for ID generation so that we can remove this deadlock from the design of hibernate? Would anyone be willing to commit such a patch? > HILO id can cause deadlock: Part deux > ------------------------------------- > > Key: HHH-1739 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3 > Environment: Hibernate 3.1.3 running JDK 1.4.1_07 Solaris 5.8 > Adaptive Server Enterprise/12.5.2/EBF 12054 ESD#2/P/Sun_svr4/OS 5.8/ase1252/1844/64-bit/FBO/Thu Aug 12 10:51:11 2004 > Reporter: Kirk Rasmussen > > Original Estimate: 1 minute > Remaining: 1 minute > > This is mostly a duplicate of HB-1246 but with a twist. I believe that there is a flaw in Hibernate's design for how it generates ids for some dialects. This is a particular problem for deep object graphs and/or at high volume. Or at least it is a problem for those of us stuck on the crappy Sybase platform. > We have an application that creates hundreds of objects that need ids generated within a single transaction. It is quite common for us to potentially exhaust the connection pool with a deep object graph. We are persisting a Trade object which has a complex and deep object graph (upwards of 100s of persistent objects). Within each trade there are roughly 15 classes which need generated ids with 30 or more instances of each class in some cases. > IMO The design flaw is when the ids are generated. From quickly browsing the source it seems that they are being generated on the fly as the objects are being processed. This can result in running of out database connections when under load or when a particular trade has a large number of persistent object instances and deadlocking the system. > A better design would be if the ids could be generated for all tables in a single transaction up front rather than issuing a whole bunch of individual transactions for each table and object. > I believe that TOPLink generates all its ids up front to avoid the described resource thrashing. It also has the configuration to generate ids from within the same transaction as the original unit of work or from a secondary unit of work. > See org.hibernate.id.MultipleHiLoPerTableGenerator -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
