[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739?page=c...
]
Per Olesen commented on HHH-1739:
---------------------------------
I don't have a fix for it, but if using JPA @TableGenerator to map to the
MultipleHiLoPerTableGenerator, consider setting the "allocationSize" property to
a higher value. This will limit the amount of times, the id/sequence table needs to be
touched, making it a lot less probable that the deadlock appears.
See
http://www.techper.net/2011/08/15/hibernate-multiplehilopertablegenerator...
HILO id can cause deadlock: Part deux
-------------------------------------
Key: HHH-1739
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects 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: 1m
Remaining Estimate: 1m
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.
For more information on JIRA, see:
http://www.atlassian.com/software/jira