db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "vodarus vodarus" <voda...@gmail.com>
Subject Re: Speed of using Derby DB
Date Thu, 19 Jun 2008 14:15:29 GMT
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

View raw message