Thanks, Dan. The document I read seems already the latest, which is Derby Developer's Guide Version 10.3. And I am still confused about the isolation mode, I traced the stored procedure using getTransactionIsolation() and the return value shows the isolation level was changed, I am not sure about the whether that data can reflect the real isolation level.
On Feb 15, 2008 11:59 PM, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > sin(EaTing), wrote: > > > *In order to preserve transactional atomicity, database-side JDBC > > procedures that use > > nested connections have the following limitations. > > • Cannot issue a commit or rollback, unless called within a CALL > statement. > > • Cannot change connection attributes such as auto-commit. > > > > * > > If these items are true for my stored procedure, then I cannot modify > > the isolation level and neither change the autocommit mode. > > The autocommit mode cannot be changed, it is always false for > server-side connections. Calling setAutoCommit(false) is allowed since > it doesn't change the mode. > > Set isolation level I'm not sure about. > > > And I am yet confused about the first statement "*Cannot issue a commit > > or rollback, unless called within a CALL statement."* Could a Derby > > procedure be called without a "CALL statement"? > > Procedures are only supported in CALL statements. However server-side > jdbc can also exist in functions which can be called from any expression. > > So the documentation you found is somewhat incorrect, it could be > improved to use routines when describing functions and procedures, and > just procedures when needed. E.g. > > In order to preserve transactional atomicity, database-side JDBC > routines that use nested connections have the following limitations. > • Can only issue a commit or rollback within a procedure. > • Cannot change connection attribute auto-commit. > > Dan. > >
