db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: multithreading
Date Wed, 29 Jun 2005 18:33:46 GMT
I am assuming that the question is that you see 2 processors being used
on a 4 processor machine
when you get a single connection through the network server and use that
single connection to do 1000 inserts - maybe through one statement?

On the server side almost all the work of a single connection is done
with a single thread, thus on a single processor (though it is up to
the OS whether it wants to move that thread around to a different
processor).  The most straight forward thing to assume is that a
derby connection query execution is always done by a single thread -
for instance it never splits a large select into scans executed in
parallel by multiple threads.  The level of multithreading is at the
connection level, every connection can be executing on a different
thread - thus a different processor.
In general derby will always uses one thread to execute
a query.  Having said that, there is a small amount of background work 
that is done
by other threads, which is mostly related to space reclamation which
will not be involved in inserts.

I would assume the other processor you see getting work is your
your client program process.

I would only expect 2 active processors in the scenario you are
describing.  If you added more client threads then depending on the
OS, I would expect the work to be distributed to the other processors.
If you looked at delete you may see the background thread come into
play.  Also if you do enough updates you may see some other background
work being done to checkpoint the buffer cache - I believe this
defaults to every 10 meg of log written.

Xavier Vigouroux wrote:
> Hi,
> I execute a networkserver on a 4 processors machine. I wonder how is 
> managed the multithreading as I can see that 2 procs are used for a 
> single batch (with 1000 insert).
> thanks.

View raw message