db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arieh Markel <Arieh.Mar...@Sun.COM>
Subject Re: Concurrency in connections and Threads
Date Thu, 10 Nov 2005 15:33:09 GMT
I have autocommit on, so - like you say - I am safe.

Thanks,

Arieh

Lars Clausen wrote On 11/10/05 08:28,:

>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
>
>
>  
>

-- 
 Arieh Markel                           Sun Microsystems Inc.
 CNS CTO - Advanced Technology          500 Eldorado Blvd. MS UBRM05-169
 e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
 http://blogs.sun.com/arieh             Phone: (303) 272-8547 x78547


Mime
View raw message