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 <djd@apache.org> 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.