> Actually, I wanted to help you, but the spec is like a prophet in
> Delphoi, it's absolutely not clear about it.

JDBC 3.0 specs is very clear on this: commit if the autocommit is
changed. :( so, we have a bug.

> r> If this is true, then it explains the behaviour: you do not see
> the
> r> change made in one transaction from another transaction until you
> r> commit that transaction. You might try to set transaction

isolation

> r> to "dirty read" and example should work.
>
> 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...

Don't use dirty reads for production. It's not safe. But dirty reads
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 it
> calls commit() when autocommit is set to true (it does not care
> about the previous value)

Now I confirm that specs require us to commit. Code I posted will do
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, but
> 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
> reliably.

I'm really sorry. :(

Best regards,
Roman Rokytskyy