[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3809) Improve Memory Management when Post Commit Listeners are enabled

[Shawn Clowater (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42070#action_42070 ] 

Shawn Clowater commented on HHH-3809:
-------------------------------------

Steve, basically the issue is that when you have any type of post commit listener it keeps EVERYTHING in the action map whether or not you care about it in the post commit.

i.e. let's say that I have 300-400 entities and I only want to do something in the post commit to 5 of them (which is about my scenario).  The ones that I want to do anything with don't have a high number of modifications to them but there are cases when we have massive processes where we need to do some manual session management and clear the session at set point so that we don't blow the heap (and also vastly improve the flushing performance).  However, with a post commit listener enabled, every modified entity is referenced in the ActionMap until the transaction is physically committed.  This becomes very problematic for long running transactions.

For the time being I ended up jacking in a flag on the session to disable post commit listeners and modded the actions to check this additional flag to prevent the references from building up.  It's very much a hack but is a temporary workaround for us.  It's the same type of behavior we used to get with the QueryCache until you guys move to the invalidating of the table spaces vs keeping the full entities around.

I think the cleanest would be to be able to register the listeners by entity but that has to be very performant as it's going to get called anytime an event occurs.


> 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
>         Attachments: HHH-5309Option1.patch
>
>
> 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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira