db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: threads and derby
Date Thu, 17 Apr 2008 18:53:02 GMT
Hi Brandon,

I can see that Kristian is already giving you excellent advice on this 
issue. You may also want to take a look at the large section titled 
"Controlling Derby application behavior" in the Derby Developer's Guide: 
http://db.apache.org/derby/docs/10.3/devguide/ In particular, you may 
find a lot of good advice in the subsections titled "The JDBC Connection 
and Transaction Model", "Locking, concurrency, and isolation", and 
"Working with database threads in an embedded environment". I also 
recommend taking a look at the "Locking and performance" section of the 
Derby Tuning Guide: http://db.apache.org/derby/docs/10.3/tuning/

If you let multiple threads use the same Connection, you may create some 
interesting consistency problems for yourself. If, on the other hand, 
you give each thread its own Connection, then your threads may block one 
another depending on many factors, including how you design your data, 
the isolation level you choose, etc.. The Developer's and Tuning Guides 
may help steer you through these issues.

Derby is a multi-user database. This means that, in a well designed 
application, many users should be able to work productively side-by-side 
in the same database.

Hope this is useful,

Brandon Dohman wrote:
> I’ve currently created a multithreaded server that is using 1 class to 
> do all of the database interactions when receiving commands from the 
> client programs.
> My question:  When my server code has multiple threads going, will the 
> database, or the java code for that matter, wait until the current 
> threads transactions are done before allowing another thread to take 
> control of the database?
> I have created a simple user login system that allows access to a 
> machine, and there will be possible multiple logins going on at the 
> same time (very possible it will never happen at the exact same time) 
> but along with logins, admin users will be updating information in the 
> database.  And I just want to make sure I won’t crash my database, if 
> I have operations trying to access things at the same time.
> Thanks
> B
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.23.0/1381 - Release Date: 
> 4/16/2008 9:34 AM

View raw message