From: Bruce A. (JIRA) <no...@at...> - 2006-03-31 18:42:29
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-1246?page=comments#action_22674 ] Bruce Atherton commented on HB-1246: ------------------------------------ Thanks for taking the time to make suggestions. We have a thread pool, and we do limit it. But we use threads for much more than just database connections. If we tried to control the number of database connections by limiting the number of threads, we would be hobbling performance in other areas of our application. This is an abstraction mismatch anyway. Limiting the number of connections should be done by the connection pool whose responsibility it is, not by a side effect from another part of the application. There is no connection leak, your guess about requests was correct. We have an Enterprise Service Bus architecture based on Mule (http://mule.codehaus.org/), and when a flood of messages are injected to it, hibernate configured with hilo deadlocks. So again, I ask that consideration be given to reopening this issue. > HILO id can cause deadlock > -------------------------- > > Key: HB-1246 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-1246 > Project: Hibernate2 > Type: Bug > Components: core > Versions: 2.1.6 > Environment: HILO id generation with a fixed connection limit > Reporter: Edward Costello > > > The HILO generator attempts to obtain a connection to the database in addition to the one being used by the current session. If no connections are available and all sessions are attempting an operation that requires ID generation, this will result in deadlock (at least until the connection pool times out the request and the exception kills one of the requesting sessions). > The simple case to observe this effect is: > 1) Set up the connection pool to provide only a single connection. > 2) Attempt to save an object using HILO id generation. > This issue can also occur when there is more than one connection available. > E.G if there are 5 connections, 5 threads open a session, all 5 attempt to save. All 5 threads will be blocked while they each try and obtain a connection for the id generator. > --- Code to Reproduce --- > Configuration cfg = new Configuration(); > cfg.configure(......); // Configured Pool must only allow 1 connection > SessionFactory sf = cfg.buildSessionFactory(); > Session s = sf.openSession(); > Transaction tx = s.beginTransaction(); > s.save(new PersistedObject()); > tx.commit(); > ---- Suggested Resolution --- > The best solution we have come up with is to allow for the configuration of a second smaller connection pool that is used exclusively for HILO (and any other generation types requiring a separate connection). > This pool would be optional and if not specified the main pool would be used (i.e. the current behaviour). -- 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 |