On Wed, 2005-11-09 at 18:18, Arieh Markel wrote: > I am using Derby in 'embedded' mode. > > A pool of worker threads takes jobs from a queue and following > processing populates different tables. > > So far, in my implementation, all threads shared the same connection. > > I am wondering whether there are any resulting concurrency issues > that I may not be aware of. > > My assumptions are as follows: > > - the threads are well behaved among themselves relative to (java) > concurrency > > - no two threads update the same database table at any given moment > > - table lock granularity is what is in place in Derby > > Based on that, the same connection (albeit processing different tables) > may be used by different threads without creating unnecessary contention. > > Are those assumptions true ?
You should be aware that each connection only has one transaction. So the following scenario (serially executed): Turn autocommit off Thread 1 executes update of table A Thread 2 executes update of table B Thread 2 executes a rollback would cause the update of table A to be rolled back as well. If autocommit is on, you're safe from this particular scenario. -Lars
