Обсуждение: 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