2008/6/19 <derby@segel.com>:

 I haven't looked at Derby's code, but just because you haven't 'committed' the transaction doesn't mean that Derby isn't writing the records.

Without a commit, depending on your isolation level, other users won't see or feel the effects of your data. The transactions are stored in a log so that you can rollback the transaction, the data is still getting written.

 (A simple test would be to write a record of a known length, X number of times, on a machine where the JVM has a set restriction size. If you think everything is in memory and not being written to disk, then after Y number of iterations, you will fill up the heap and go boom.)

 But Derby can be different so what do I know?


I don't know how it works, but it seems that Derby eat a lot of CPU and can not use HDD at full speed.

it seems to my that CPU is bottleneck for application. May be because of data transformation to RecordSet and all manipulations are doing from high level, not from low and data-storage.

Is there any abilities for Derby to have algorithm working with data on lowest levels of DBMS? As it do other DBMS like MySQL / PostgreSQL / Oracle ?