[Hibernate-JIRA] Created: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator
12:45 p.m.
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
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
2:51 p.m.
New subject: [Hibernate-JIRA] Assigned: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Steve Ebersole reassigned HHH-7239:
-----------------------------------
Assignee: Steve Ebersole
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
2:51 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Steve Ebersole updated HHH-7239:
--------------------------------
Fix Version/s: 4.1.3
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
4:04 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Shawn Clowater commented on HHH-7239:
-------------------------------------
Added pull request @ https://github.com/hibernate/hibernate-orm/pull/307 that adds a few
unit tests showing some of the issues.
I added a third test that illustrates that currently if you have a managed session as the
secondary session and it is closed, either manually or automatically it will blow a
session already closed from the transaction observer if it is called after the session is
closed.
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
2:16 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Steve Ebersole commented on HHH-7239:
-------------------------------------
Shawn, do you happen to either have the log from when we discussed this on IRC or remember
the date we discussed it?
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
2:47 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Steve Ebersole commented on HHH-7239:
-------------------------------------
Found it!
http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/20...
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
11:53 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Shawn Clowater commented on HHH-7239:
-------------------------------------
Excellent, my hack has been holding together fine. I'll pop my head back up next week
when I get a chance to breathe.
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
2:23 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Shawn Clowater commented on HHH-7239:
-------------------------------------
Added another pull request @ https://github.com/hibernate/hibernate-orm/pull/321
I think I might have hooped it up a bit since it picked up the initial commit as well that
had the tests. I couldn't figure out how to isolate it to the single commit. Let me
know if I've caused you undue grief.
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
7:36 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-7239) have session remove itself from list of transaction observers on close
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Steve Ebersole updated HHH-7239:
--------------------------------
Summary: have session remove itself from list of transaction observers on close
(was: centralize before/after transaction callbacks in TransactionCoordinator)
have session remove itself from list of transaction observers on
close
-----------------------------------------------------------------------
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
12:43 p.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-7239) have session remove itself from list of transaction observers on close
[
https://hibernate.onjira.com/browse/HHH-7239?page=com.atlassian.jira.plug...
]
Steve Ebersole resolved HHH-7239.
---------------------------------
Resolution: Fixed
have session remove itself from list of transaction observers on
close
-----------------------------------------------------------------------
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
Time Spent: 7h 5m
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
4569
days inactive
4591
days old
hibernate-issues@lists.jboss.org
9 comments
2 participants
participants (2)
-
Shawn Clowater (JIRA) -
Steve Ebersole (JIRA)