Subject | Re: [Firebird-Java] Re: Serious issue or bug with transactions |
---|---|
Author | Marczisovszky Daniel |
Post date | 2002-04-11T22:06:05Z |
r> Hi,
r> I just looked through the code and I didn't find the con.commit().
Yes, that is right, I have not used that, since in auto-commit I
assumed there is need for that, and changePassword is in auto-commit
mode.
r> There might be a bug in driver (or more correctly, non-implemented
r> specs) when driver should commit in setAutoCommit(...) and
r> setTransactionIsolation(...) methods. I have to check the specs.
Actually, I wanted to help you, but the spec is like a prophet in
Delphoi, it's absolutely not clear about it.
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...
r> I will check the specs on this issue. Also, it might take some time
r> to add this feature because we have to check if there's no side
r> effects in case of JCA. But you might add this to your source code if
r> you have non-managed case: in methods FBConnection.setAutoCommit
r> (boolean) and in FBConnection.setTransactionIsolation(int) add the
r> following code on the begining of the method:
r> if (inTransaction())
r> commit();
r> But again, I'm not sure if this is the reason, and if the code above
r> is compliant with specs.
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)
r> Best regards,
r> Roman Rokytskyy
r> P.S. BTW, are encodings working in your application?
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.
So this had high priority over encodings ;) But I'll check them soon.
Many thanks for prompt help,
daniel
r> I just looked through the code and I didn't find the con.commit().
Yes, that is right, I have not used that, since in auto-commit I
assumed there is need for that, and changePassword is in auto-commit
mode.
r> There might be a bug in driver (or more correctly, non-implemented
r> specs) when driver should commit in setAutoCommit(...) and
r> setTransactionIsolation(...) methods. I have to check the specs.
Actually, I wanted to help you, but the spec is like a prophet in
Delphoi, it's absolutely not clear about it.
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...
r> I will check the specs on this issue. Also, it might take some time
r> to add this feature because we have to check if there's no side
r> effects in case of JCA. But you might add this to your source code if
r> you have non-managed case: in methods FBConnection.setAutoCommit
r> (boolean) and in FBConnection.setTransactionIsolation(int) add the
r> following code on the begining of the method:
r> if (inTransaction())
r> commit();
r> But again, I'm not sure if this is the reason, and if the code above
r> is compliant with specs.
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)
r> Best regards,
r> Roman Rokytskyy
r> P.S. BTW, are encodings working in your application?
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.
So this had high priority over encodings ;) But I'll check them soon.
Many thanks for prompt help,
daniel