Menu
▾
▴
hibernate-issues
|
From: <leg...@at...> - 2004-09-30 05:31:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/browse/HB-1246 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-1246 Summary: HILO id can cause deadlock Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate2 Components: core Versions: 2.1.6 Assignee: Reporter: Edward Costello Created: Thu, 30 Sep 2004 1:02 AM Updated: Thu, 30 Sep 2004 1:02 AM Environment: HILO id generation with a fixed connection limit Description: 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). --------------------------------------------------------------------- JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2004-09-30 06:06:02
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 30 Sep 2004 1:37 AM
Body:
Hum. Interesting. This never occurred to me.
I really don't see a good solution, other than "don't use a connection pool which limits the number of open connections". (But I think a lot do.)
---------------------------------------------------------------------
View this comment:
http://opensource.atlassian.com/projects/hibernate/browse/HB-1246?page=comments#action_14499
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/browse/HB-1246
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-1246
Summary: HILO id can cause deadlock
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Versions:
2.1.6
Assignee:
Reporter: Edward Costello
Created: Thu, 30 Sep 2004 1:02 AM
Updated: Thu, 30 Sep 2004 1:37 AM
Environment: HILO id generation with a fixed connection limit
Description:
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).
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2004-10-26 11:42:57
|
Message: The following issue has been resolved as WON'T FIX. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/browse/HB-1246 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-1246 Summary: HILO id can cause deadlock Type: Bug Status: Resolved Priority: Major Resolution: WON'T FIX Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate2 Components: core Versions: 2.1.6 Assignee: Reporter: Edward Costello Created: Thu, 30 Sep 2004 1:02 AM Updated: Tue, 26 Oct 2004 7:18 AM Environment: HILO id generation with a fixed connection limit Description: 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). --------------------------------------------------------------------- JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: Bruce A. (JIRA) <no...@at...> - 2006-03-30 16:32:20
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-1246?page=comments#action_22656 ] Bruce Atherton commented on HB-1246: ------------------------------------ This one has bit us badly during load testing. We tried the "don't use a connection pool which limits the number of open connections", but that just led to hitting the connection limit on the database. We've had to abandon hilo and turn to native, which is causing us other kinds of grief. There is an easy solution for this bug, though. Just allow the user the option to define a separate connection pool for the hilo generator. Anyone who runs into this deadlock issue can then configure the generator to draw from a different data source. Can I request that this issue be reopened with that solution in mind? > 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 |
|
From: Edward C. (JIRA) <no...@at...> - 2006-03-31 00:06:15
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-1246?page=comments#action_22664 ] Edward Costello commented on HB-1246: ------------------------------------- If your've got as many sessions open as the database connection limit I'm going to guess you either have a connection leak or you're spawning a new thread for each request. If it's the later case then I'd suggest you consider a Thread pool such as http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.html avaliable for download at http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html If you set the size of the thread pool below the size of your connection pool you won't ever hit this deadlock problem. It will of couse limit the concurrent requests to the size of the thread pool but will cause the application to degrade more gracefully (i.e. slowing down rather than cannot get a connection errors) under load. > 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 |
|
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 |
|
From: Kirk R. (JIRA) <no...@at...> - 2006-05-10 18:16:14
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-1246?page=comments#action_23071 ] Kirk Rasmussen commented on HB-1246: ------------------------------------ I agree with Bruce. At what point are ids generated? Are they all created up front when the transaction begins or on the fly as the objects are being processed? I can see this as being a problem if it is done on the fly. It would be better if ids could be generated for all tables in a single transaction up front rather than a whole bunch of individual transactions for each table and object. 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. Within each trade there are probably 10 classes which need generated ids (Sybase) with 30 or more instances of each class in some cases. > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X