Improve Memory Management when Post Commit Listeners are enabled ---------------------------------------------------------------- Key: HHH-3809 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3809 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Environment: N/A Reporter: Shawn Clowater This is somewhat related to the QueryCache behavior reported under http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028 In this particular case however, it is the fact that when the session factory is configured to have post commit listeners it prevents the garbage collection of any entity that is modified during the session due to the fact that it is referenced in the executions list in the ActionQueue class. This makes any type of memory management by flushing/clearing the session ineffective if you're in the middle of a large batch that is inserting or updating a large amount of data. i.e in our case we have 4 entities out of possibly 300 or so that we want to notify external systems if they change. However, by simply having the listeners defined they essentially block the remaining entities in the executions. A potential workaround I guess might be to keep 2 session factories around with a different set of listeners but that seems a bit dirty. There are 2.5 potential ways that I can think of that might address this. 1 - Have some sort of flag on the session to disable the post commit listeners. The onus would be on the user of the session to disable the listeners in the case where they know they aren't modifying anything that will need post commit handling. 2 - Add the ability to configure the post commit listeners by entity a)With polymorphism - i.e. you could add a listener based on Object.class and it would apply to all entities and would behave much like it does now. You could also configure to Animal.class and would include Cat and Dog. b)Without polymorphism - you could add a listener based on a specific entity class and it would only apply to that particular one. You would have an option to specify a null entity and it would default to what is there today. In my miind, 2a is probably the best albeit slightly more complex to implement but I think would be a good value add. I don't mind submitting a patch assuming that I'm not so far in left field that I should be committed. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira