|Subject||Re: Serious issue or bug with transactions|
> Actually, I wanted to help you, but the spec is like a prophet inJDBC 3.0 specs is very clear on this: commit if the autocommit is
> Delphoi, it's absolutely not clear about it.
changed. :( so, we have a bug.
> r> If this is true, then it explains the behaviour: you do not seeisolation
> r> change made in one transaction from another transaction until you
> r> commit that transaction. You might try to set transaction
> r> to "dirty read" and example should work.Don't use dirty reads for production. It's not safe. But dirty reads
> Thanks, I will do so, I would have thought that... But actually I
> don't know if it's a good idea for me now, as this happened in a
> heavily multithreaded environment :( At first I even did not where
> to start debugging...
might be helpful to find the transaction handling bugs. however, this
is not the case.
> Fine, I'll check this. I checked the Postgres JDBC driver and itNow I confirm that specs require us to commit. Code I posted will do
> calls commit() when autocommit is set to true (it does not care
> about the previous value)
the trick for unmanaged scenario. I'm waiting for David's response on
managed scenario before I try to fix it.
> Sorry, I have no time to check that. Encodings are important, butI'm really sorry. :(
> they are just a game, if they don't work, I'll change the driver
> for my needs, but this issue... Hm... It took two days (and a
> night :( ) to find it out, because this happened very rare and I
> did not how to reproduce that. It took me almost for a day even to
> create such a small example code the reproduces this behaviour