Re: [T5] tapestry-hibernate and transactions
Hi guys,
I have run into a related issue. I am using a thrid party library which
creates transactions, commits and also performs rollbacks internally. When
ever a transaction is rolledback in the third party library I later see a
hibernate exception in the log file:
org.hibernate.TransactionException: Transaction not successfully started
at
org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:149)
at
org.apache.tapestry5.internal.hibernate.HibernateSessionManagerImpl.threadDidCleanup(HibernateSessionManagerImpl.java:65)
ThreadDidCleanup looks like this in tapestry-hibernate:
public void threadDidCleanup()
{
transaction.rollback();
session.close();
}
The problem is because threadDidCleanup() is not checking to see if it's
internal reference has already been rolled back (somewhere else) before
calling rollback (via Transaction.wasRolledback()).
I'm not sure if I should file a new JIRA or re-open
https://issues.apache.org/jira/browse/TAPESTRY-2454. Please advise.
thanks,
B
--
View this message in context:
http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-tp17767677p19300096.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] tapestry-hibernate and transactions
ok, Howard, I added the bug to JIRA. Regards. Howard Lewis Ship wrote: > > Before making changes, I'm checking on the Hibernate user forum. > > http://forum.hibernate.org/viewtopic.php?p=2387715#2387715 > > Please still add the bug to JIRA. > > On Wed, Jun 11, 2008 at 9:53 AM, Howard Lewis Ship <[EMAIL PROTECTED]> > wrote: >> Thanks for the heads up. >> >> Looking at the Hibernate source, I can see that this is true, when you >> commit() a transaction, the Session's connection to the transaction >> (via the JDBCContext) is lost. It seems like, at least for the JDBC >> case, the Transaction object should only have begin() invoked once. >> >> Please add a bug to JIRA; I'll change the source to invoke >> session.beginTransaction() rather than Transaction.begin() after >> commit or rollback. >> >> On Tue, Jun 10, 2008 at 5:30 PM, raulmt <[EMAIL PROTECTED]> wrote: >>> >>> Hi, >>> >>> I'm using T5.0.12, Hibernate 3.2.6GA and MySQL 5.1. I ran into a problem >>> when I wanted to make two commits on the same request. The first commit >>> worked fine, but the second works "partially" (for example, an entity >>> deletion on the second transaction doesn't ocurr). >>> >>> Debugging, I realized that before the first call to >>> HibernateSessionManager.commit(), if I call >>> hsm.getSession().getTransaction() (which gets the underlying transaction >>> from the jdbcContext), the Transaction returned is the same instance >>> that is >>> stored in a property on the hsm, but after calling hsm.commit(), >>> hsm.getSession().getTransaction() returns another instance of >>> Transaction... >>> >>> I guess the problem is that hsm.commit() after committing the >>> transaction it >>> obtained when created the Session, instead of obtaining again the >>> (apparently new) underlying transaction calling >>> session.getTransaction(), it >>> calls begin() on the same transaction it has stored on its property, >>> which >>> isn't the real underlying transaction and because of that, the >>> transaction >>> doesn't really begin again. If, after calling hsm.commit() I do a >>> hsm.getSession().getTransaction().begin() (which I assume really starts >>> another transaction on the database) all works perfectly. >>> >>> I'm not neither a Tapestry nor Hibernate expert, but I think maybe >>> hsm.commit() should get again the transaction with >>> session.getTransaction >>> after it commits the current transaction. >>> >>> Regards. >>> -- >>> View this message in context: >>> http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-tp17767677p17767677.html >>> Sent from the Tapestry - User mailing list archive at Nabble.com. >>> >>> >>> --------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator Apache Tapestry and Apache HiveMind >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-tp17767677p17784231.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] tapestry-hibernate and transactions
Before making changes, I'm checking on the Hibernate user forum. http://forum.hibernate.org/viewtopic.php?p=2387715#2387715 Please still add the bug to JIRA. On Wed, Jun 11, 2008 at 9:53 AM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > Thanks for the heads up. > > Looking at the Hibernate source, I can see that this is true, when you > commit() a transaction, the Session's connection to the transaction > (via the JDBCContext) is lost. It seems like, at least for the JDBC > case, the Transaction object should only have begin() invoked once. > > Please add a bug to JIRA; I'll change the source to invoke > session.beginTransaction() rather than Transaction.begin() after > commit or rollback. > > On Tue, Jun 10, 2008 at 5:30 PM, raulmt <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> I'm using T5.0.12, Hibernate 3.2.6GA and MySQL 5.1. I ran into a problem >> when I wanted to make two commits on the same request. The first commit >> worked fine, but the second works "partially" (for example, an entity >> deletion on the second transaction doesn't ocurr). >> >> Debugging, I realized that before the first call to >> HibernateSessionManager.commit(), if I call >> hsm.getSession().getTransaction() (which gets the underlying transaction >> from the jdbcContext), the Transaction returned is the same instance that is >> stored in a property on the hsm, but after calling hsm.commit(), >> hsm.getSession().getTransaction() returns another instance of Transaction... >> >> I guess the problem is that hsm.commit() after committing the transaction it >> obtained when created the Session, instead of obtaining again the >> (apparently new) underlying transaction calling session.getTransaction(), it >> calls begin() on the same transaction it has stored on its property, which >> isn't the real underlying transaction and because of that, the transaction >> doesn't really begin again. If, after calling hsm.commit() I do a >> hsm.getSession().getTransaction().begin() (which I assume really starts >> another transaction on the database) all works perfectly. >> >> I'm not neither a Tapestry nor Hibernate expert, but I think maybe >> hsm.commit() should get again the transaction with session.getTransaction >> after it commits the current transaction. >> >> Regards. >> -- >> View this message in context: >> http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-tp17767677p17767677.html >> Sent from the Tapestry - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] tapestry-hibernate and transactions
Thanks for the heads up. Looking at the Hibernate source, I can see that this is true, when you commit() a transaction, the Session's connection to the transaction (via the JDBCContext) is lost. It seems like, at least for the JDBC case, the Transaction object should only have begin() invoked once. Please add a bug to JIRA; I'll change the source to invoke session.beginTransaction() rather than Transaction.begin() after commit or rollback. On Tue, Jun 10, 2008 at 5:30 PM, raulmt <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm using T5.0.12, Hibernate 3.2.6GA and MySQL 5.1. I ran into a problem > when I wanted to make two commits on the same request. The first commit > worked fine, but the second works "partially" (for example, an entity > deletion on the second transaction doesn't ocurr). > > Debugging, I realized that before the first call to > HibernateSessionManager.commit(), if I call > hsm.getSession().getTransaction() (which gets the underlying transaction > from the jdbcContext), the Transaction returned is the same instance that is > stored in a property on the hsm, but after calling hsm.commit(), > hsm.getSession().getTransaction() returns another instance of Transaction... > > I guess the problem is that hsm.commit() after committing the transaction it > obtained when created the Session, instead of obtaining again the > (apparently new) underlying transaction calling session.getTransaction(), it > calls begin() on the same transaction it has stored on its property, which > isn't the real underlying transaction and because of that, the transaction > doesn't really begin again. If, after calling hsm.commit() I do a > hsm.getSession().getTransaction().begin() (which I assume really starts > another transaction on the database) all works perfectly. > > I'm not neither a Tapestry nor Hibernate expert, but I think maybe > hsm.commit() should get again the transaction with session.getTransaction > after it commits the current transaction. > > Regards. > -- > View this message in context: > http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-tp17767677p17767677.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[T5] tapestry-hibernate and transactions
Hi, I'm using T5.0.12, Hibernate 3.2.6GA and MySQL 5.1. I ran into a problem when I wanted to make two commits on the same request. The first commit worked fine, but the second works "partially" (for example, an entity deletion on the second transaction doesn't ocurr). Debugging, I realized that before the first call to HibernateSessionManager.commit(), if I call hsm.getSession().getTransaction() (which gets the underlying transaction from the jdbcContext), the Transaction returned is the same instance that is stored in a property on the hsm, but after calling hsm.commit(), hsm.getSession().getTransaction() returns another instance of Transaction... I guess the problem is that hsm.commit() after committing the transaction it obtained when created the Session, instead of obtaining again the (apparently new) underlying transaction calling session.getTransaction(), it calls begin() on the same transaction it has stored on its property, which isn't the real underlying transaction and because of that, the transaction doesn't really begin again. If, after calling hsm.commit() I do a hsm.getSession().getTransaction().begin() (which I assume really starts another transaction on the database) all works perfectly. I'm not neither a Tapestry nor Hibernate expert, but I think maybe hsm.commit() should get again the transaction with session.getTransaction after it commits the current transaction. Regards. -- View this message in context: http://www.nabble.com/-T5--tapestry-hibernate-and-transactions-tp17767677p17767677.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
