Looks good, except I think if setAutocommit(false) is called you should not
start a new transaction until work is started. This would be consistent
with (a), agreed?

david jencks

On 2002.12.05 17:59:12 -0500 Roman Rokytskyy wrote:
> Hi,
>
> I have changed transaction behavior on my computer and I'm ready to
> commit. All test cases succeeded (except TestFBDriver.testWarnings(),
> I will check if this is a Linux/CS specific issue). My changes were:
>
> a) no transaction is started right after commit/rollback;
> b) setTransactionIsolation() calls commit and then modifies TPB;
> c) TRANSACTION_NONE and TRANSACTION_READ_UNCOMMITTED are not supported
> and are promoted to TRANSACTION_READ_COMMITTED.
>
> Also there are one place where I'm not sure what to do:
> setAutoCommit() commits transaction before changing the auto-commit
> value, and later starts a new transaction if new mode is not
> auto-commit. Do you have any ideas if this is correct or not?
>
> If nobody has any objection to my changes I will commit them into the
> CVS tomorrow in the evening (~22:00 UTC).
>
> Also I was not able to find any place in the code where statement
> handle is deallocated in commit or rollback. The only thing I found
> was that we close result sets (isc_dsql_free_statemet() with
> DSQL_close option) in commit or rollback. And I think this is correct
> behavior.
>
> If I missed something, please provide a test case or at least an
> execution path that can lead to deallocating statement on transaction
> end.
>
>
> Best regards,
> Roman Rokytskyy
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>