[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator

[Steve Ebersole (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46409#comment-46409 ] 

Steve Ebersole commented on HHH-7239:
-------------------------------------

Found it!  http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2012/%23hibernate-dev.2012-04-10.log

> centralize before/after transaction callbacks in TransactionCoordinator
> -----------------------------------------------------------------------
>
>                 Key: HHH-7239
>                 URL: https://hibernate.onjira.com/browse/HHH-7239
>             Project: Hibernate ORM
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 4.1.2
>         Environment: Hibernate 4.1.2, database n/a
>            Reporter: Shawn Clowater
>            Assignee: Steve Ebersole
>             Fix For: 4.1.3
>
>
> There are 2 issues that came to light during extended testing of the Shared Transaction impl.
> 1st issue is that when a Session is opened during a shared transaction scenario it registers a TransactionObserver with the TransactionCoordinatorImpl to perform operations such as managedFlush and manageClose calls on the child sessions.  This observer is not release until the transaction completes so even if the session is closed it can never be garbage collected.
> 2nd issue is that the afterTransaction/beforeTransaction processes are registered with the ActionQueue belonging to a Session and when the transaction coordinator completes the transaction it only calls the afterTransactionCompletion on the Session that owns the TransactionCoordinator and not any of the child sessions.
> Originally suggested that the session remove itself from the observer list on close and that the created observer should also call the before/after transaction methods but an alternative solution was discussed where the TransactionCoordinator and not the ActionQueue would be where the after transaction processes are registered.  The ActionQueue would register actions with the Coordinator vs. keeping its own lists.
> Test cases showing both scenarios to follow shortly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira