You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Buck O' Five (JIRA)" <de...@tapestry.apache.org> on 2008/09/11 04:34:44 UTC
[jira] Created: (TAPESTRY-2659) org.hibernate.TransactionException
thrown when a transaction is directly rolledback (outside of
tapestry-hibernate)
org.hibernate.TransactionException thrown when a transaction is directly rolledback (outside of tapestry-hibernate)
-------------------------------------------------------------------------------------------------------------------
Key: TAPESTRY-2659
URL: https://issues.apache.org/jira/browse/TAPESTRY-2659
Project: Tapestry
Issue Type: Bug
Components: tapestry-hibernate
Affects Versions: 5.0.15
Reporter: Buck O' Five
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to not retain the reference to the transaction as explained in this post: http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-td17767677.html#a19300096
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-2659) org.hibernate.TransactionException
thrown when a transaction is directly rolledback (outside of
tapestry-hibernate)
Posted by "Buck O' Five (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Buck O' Five updated TAPESTRY-2659:
-----------------------------------
Description:
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() or HibernateSessionManagerImpl abort() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to refrain from keeping a reference to the transaction and always call Session.beginTransaction().
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
was:
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to refrain from keeping a reference to the transaction and always call Session.beginTransaction().
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
> org.hibernate.TransactionException thrown when a transaction is directly rolledback (outside of tapestry-hibernate)
> -------------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-2659
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2659
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-hibernate
> Affects Versions: 5.0.15
> Reporter: Buck O' Five
> Priority: Minor
>
> A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() or HibernateSessionManagerImpl abort() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to refrain from keeping a reference to the transaction and always call Session.beginTransaction().
> Q. Why not just inject HibernateSessionManager and call abort()?
> A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-2659) org.hibernate.TransactionException
thrown when a transaction is directly rolledback (outside of
tapestry-hibernate)
Posted by "Buck O' Five (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Buck O' Five updated TAPESTRY-2659:
-----------------------------------
Priority: Minor (was: Major)
Description:
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to not retain the reference to the transaction as suggested in this post: http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-td17767677.html#a19300096
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
was:
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to not retain the reference to the transaction as explained in this post: http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-td17767677.html#a19300096
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
> org.hibernate.TransactionException thrown when a transaction is directly rolledback (outside of tapestry-hibernate)
> -------------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-2659
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2659
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-hibernate
> Affects Versions: 5.0.15
> Reporter: Buck O' Five
> Priority: Minor
>
> A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to not retain the reference to the transaction as suggested in this post: http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-td17767677.html#a19300096
> Q. Why not just inject HibernateSessionManager and call abort()?
> A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-2659) org.hibernate.TransactionException
thrown when a transaction is directly rolledback (outside of
tapestry-hibernate)
Posted by "Buck O' Five (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Buck O' Five updated TAPESTRY-2659:
-----------------------------------
Description:
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to not retain the reference and always call Session.beginTransaction().
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
was:
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to not retain the reference to the transaction as suggested in this post: http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-td17767677.html#a19300096
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
> org.hibernate.TransactionException thrown when a transaction is directly rolledback (outside of tapestry-hibernate)
> -------------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-2659
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2659
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-hibernate
> Affects Versions: 5.0.15
> Reporter: Buck O' Five
> Priority: Minor
>
> A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to not retain the reference and always call Session.beginTransaction().
> Q. Why not just inject HibernateSessionManager and call abort()?
> A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-2659) org.hibernate.TransactionException
thrown when a transaction is directly rolledback (outside of
tapestry-hibernate)
Posted by "Buck O' Five (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Buck O' Five updated TAPESTRY-2659:
-----------------------------------
Description:
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to refrain from keeping a reference to the transaction and always call Session.beginTransaction().
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
was:
A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to not retain the reference and always call Session.beginTransaction().
Q. Why not just inject HibernateSessionManager and call abort()?
A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
> org.hibernate.TransactionException thrown when a transaction is directly rolledback (outside of tapestry-hibernate)
> -------------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-2659
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2659
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-hibernate
> Affects Versions: 5.0.15
> Reporter: Buck O' Five
> Priority: Minor
>
> A "org.hibernate.TransactionException: Transaction not successfully started " occurs when a transaction is rolledback in tapestry-hibernate if the transaction has previously been rolledback. The problem is because HibernateSessionManagerImpl retains a reference to the transaction. So when HibernateSessionManagerImpl .threadDidCleanup() is called it does not first check to see if the transaction reference has been rolled back (somewhere else) before calling rollback. One possible fix would be to call Transaction.wasRolledback() to determine if tapestry-hibernate should call trans.rollback(). Another would be to refrain from keeping a reference to the transaction and always call Session.beginTransaction().
> Q. Why not just inject HibernateSessionManager and call abort()?
> A. Because there are times when you do not have control over the code calling trans.rollback() for example in a third party library (which is how I ran into this).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org