Обсуждение: Transaction handling through java
I am facing the following problem. Our application sends a block of queries to postgres in a begin end block. If one of the queries take a long time to finishthe whole transaction is assumed to be committed by the application even though the query is still running . This resultsin failure of all subsequent transactions. Although the application is programmed to catch all exceptions , it somehow is not able to figure out that the transactionis still not complete. I am using postgres 8.3 with regards Nalini
Hi, > I am facing the following problem. > > Our application sends a block of queries to postgres in a begin end > block. If one of the queries take a long time to finish the whole > transaction is assumed to be committed by the application even though > the query is still running . This results in failure of all subsequent > transactions. > > Although the application is programmed to catch all exceptions , it > somehow is not able to figure out that the transaction is still not > complete. I may be missing something, but it seems to me that the problem is your application wrongly assuming that queries taking a long time to finish are assumed to be already committed? -- Guillaume Cottenceau
Hi, If you are using a connection pooling, then may be the pool manager is closing the connection if connection has been idle for a long time (if some code is there that takes long) after it has been opened. If the connections remains open for long time, pool manager may consider of it as abandoned and can take back in the pool. If you are using DBCP connection pooling, try changing 'removeAbandonedTimeout' parameter to a bigger value. regards, Pushker nalini wrote: > I am facing the following problem. > > Our application sends a block of queries to postgres in a begin end block. If one of the queries take a long time to finishthe whole transaction is assumed to be committed by the application even though the query is still running . This resultsin failure of all subsequent transactions. > > Although the application is programmed to catch all exceptions , it somehow is not able to figure out that the transactionis still not complete. > > I am using postgres 8.3 > > with regards > > Nalini > > The information contained in this electronic message and any attachments to this message are intended for the exclusive useof the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient,you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy theoriginal message all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for thepresence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Please do not print this email unless it is absolutely necessary.
I am using Jboss application server on rhel 5. I have knowingly not configured anything which assumes that long running queries are to assumed as committed. Moreover if I restart the database when the query is still running, the transaction should be rolled back in totality, insteadof that the roll back is unpredictable and messy i.e if 3rd query took a long time to finish then after restart 1and 4th queries are rolled back but the 2nd and 3rd are not, the sequence may vary but it is never as it should be. with regards > Hi, > > > I am facing the following problem. > > > > Our application sends a block of queries to postgres in a > begin end > > block. If one of the queries take a long time to finish the whole > > transaction is assumed to be committed by the application even > though> the query is still running . This results in failure of > all subsequent > > transactions. > > > > Although the application is programmed to catch all exceptions > , it > > somehow is not able to figure out that the transaction is > still not > > complete. > > I may be missing something, but it seems to me that the problem > is your application wrongly assuming that queries taking a long > time to finish are assumed to be already committed? > > -- > Guillaume Cottenceau