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 |