db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike matrigali <mikema...@gmail.com>
Subject Re: Implicit commit and end of SYSCS_UTIL.SYSCS_IMPORT_TABLE?
Date Mon, 04 Nov 2013 18:54:53 GMT
I think you must be right, and likely we should document it.

For performance during import with replace the system does not
log each insert, instead it "knows" that it can abort by just
putting an empty table.  If you don't commit after this then
I think you start getting a mix of log records in the abort
stream.

At least in 10.7 doc we note that derby does this commit, but the
section seems to have disappeared in later releases:
http://db.apache.org/derby/docs/10.7/tools/ctoolsimport27052.html

it says:
Database transactions
     You should issue either a COMMIT or ROLLBACK statement to complete 
all transactions and release all table-level locks before you invoke an 
import or export procedure. Derby issues a COMMIT or a ROLLBACK 
statement after each import and export procedure is run.
     Note: Imports are transactional. If an error occurs during bulk 
import, all changes are rolled back.

On 11/4/2013 8:37 AM, Dag H. Wanvik wrote:
> Hi,
>
> I read our reference manual for import table, but it doesn't mention
> this. Can anyone explain why we
> do an implicit commit? I thought the import statement was transactional;
> I can imagine
> it's because with replace option we truncate the old table would roll
> back not via the log but by undoing the creation of a replacement
> conglomerate.
>
> In any case, the reference manual should mention this prominently, I think.
>
> Code reference: line 1580
> http://svn.apache.org/viewvc/db/derby/code/branches/10.10/java/engine/org/apache/derby/catalog/SystemProcedures.java?view=markup
>
>
> I'll file a doc issue if this is as it should be.
>
> Thanks,
> Dag
>


Mime
View raw message