> I have been looking at the problems Jacob had with cloudscape and it
> looks like another setAutoCommit problem (like the one Raj is having).
>
> Some background (see 212 & 473)
> http://www.cloudscape.com/support/faq.jsp?module=4&showall=yes
> "Some products have held cursors, which permits cursors to stay open
> past commits; however, Cloudscape does not have that functionality.
> Committing a
> transaction closes all open ResultSet objects and currently executing
> statements. You also need to be careful to process all results sets
> prior to issuing a commit in
> your code."
>
> When executing read-only methods outside start/commit the
> connection.autocommit is set to true.
> This gives the problems with cloudscape when using
> "retrieveRevisionDescriptors".
> In that method there is a select statement that is closed inside a loop
> over another resultset, when the inner statement is closed, an
> autocommit occurs and the outher statement is closed with as result, a
> SQLException.
>
> There are 2 solutions for this problem.
> 1) Untangle the 2 loops. Put the results of the first in a vector and
> use the vector to loop.
>
> 2) always have autocommit=false. We set this in connect and remove the
> setAutoCommits from start,commit and rollback.
> I would also do a connection.rollback in the start method.
>
> Personally, I would go with option 2 but this changes the behaviour when
> you are not inside a (slide)transaction.
> Now all changes are silently committed, with option 2 all changes
> outside a (slide)transaction are discarded.
>
> Remarks?
2 looks better, but if I remember well, there are still a few write
operations done outside a transaction (during init, and also maybe when
automatically creating revision descriptors). So this looks like a good
idea, but we have to be careful.
Remy
