Looking at the code, I don't think Derby does anything special for batch updates. org.apache.derby.impl.jdbc.EmbedStatement.executeBatch() method simply executes one statement in the batch at a time. This is from a quick look at the code and hence I could be mistaken.
On 8/9/05, Jonathan Eric Miller <firstname.lastname@example.org> wrote:
From what I remember, I found that if you're doing batch updates, using JDBC
batch updates improves performance greatly with Derby. Using
PreparedStatements alone was much slower than other DBMSs such as MySQL or
----- Original Message -----
From: "David Van Couvering" <
To: "Derby Discussion" <email@example.com>
Sent: Tuesday, August 09, 2005 11:24 AM
Subject: Re: Thread on Derby on The Server Side
> Thanks, Sunitha, for looking into this! It would be *great* if you
> posted this to the server side in response to the "Derby is slow"
> judgement out there. If for whatever reason you are uncomfortable
> doing this, let me know, and I'll be happy to do it with your OK.
> These seem to be the two most common mistakes: assuming a database is
> transactional when it's not really (doesn't sync to disk) and not
> preparing statements. We ran into this at Sun as well with a group doing
> performance tests of Derby.
> We should have a "cheat sheet" for things people should look at when
> doing internal benchmarking of Derby and make sure it's front and center
> on our web site...
> Sunitha Kambhampati wrote:
>> I took a quick look at the benchmark at polepos that is mentioned in
>> the thread on theserverside , specially the bahrain test. This test
>> uses Statements instead of PreparedStatement for the select queries.
>> ( see BahrainJdbc.java where select queries are like "select * from
>> bahrain where LicenseID=" + i
>> One important performance tip is to use PreparedStatement with
>> dynamic markers instead of Statements. This can show considerable
>> If you use Statement with literal values as in the case above, that
>> will involve derby having to compile a query plan for each of the
>> statements which affects performance. Using PreparedStatement with
>> dynamic markers ('?') avoids unnecessary compilation cost , and thus
>> So for example - if you are executing the query above(in 1st para)
>> with different LicenseID values, using a Statement will involve
>> compilation cost for each statement executed. But in case of
>> PreparedStatement, the query would be ' select * from bahrain where
>> LicenseID=?" and the statement is compiled only the first time or when
>> the optimizer thinks the plan is stale.
>> Check out the tuning manual for more details :-
>> Also I think, sometimes default behaviors of databases are different
>> and this can lead to different performance out of the box - some key
>> factors such as the default isolation level, I/O syncs on a commit or
>> not. When I looked at the docs for HSQLDB and Pointbase last, I saw
>> that by default they dont force a sync call to the disk on a commit.
>> ps: There are some more differences documented in Derby-110 comments,
>> and also in Dan's blog entry.
>>> Daniel Noll wrote:
>>>> David Van Couvering wrote:
>>>>> Note there are suggestions Derby is slow. If anyone wants to chime
>>>>> in on some of this, that would be great. We don't want the "word"
>>>>> to get out that Derby is slow if it's based on poorly designed
>>>>> benchmarks or misconceptions...
>>>> Derby does have an inexplicable 8-12 second wait when creating or
>>>> opening a database where HSQLDB has no noticeable wait, which
>>>> doesn't hurt on a server but on a desktop client it's a bit of a
>>>> problem. It really makes our unit tests grind too, since we use a
>>>> fresh database for each test case.
>>>> But that being said, at runtime (which is normally what matters) we
>>>> haven't encountered any noticeable slowdown using Derby over HSQLDB.
>>>> Maybe someone has some quantitative figures though, instead of these
>>>> qualitative experiences.