I have autocommit on, so - like you say - I am safe.Thanks,AriehLars 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 followingprocessing populates different tables.So far, in my implementation, all threads shared the same connection.I am wondering whether there are any resulting concurrency issuesthat 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 DerbyBased 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. Sothe following scenario (serially executed):Turn autocommit offThread 1 executes update of table AThread 2 executes update of table BThread 2 executes a rollbackwould cause the update of table A to be rolled back as well. Ifautocommit is on, you're safe from this particular scenario.-Lars
--Arieh Markel Sun Microsystems Inc.CNS CTO - Advanced Technology 500 Eldorado Blvd. MS UBRM05-169e-mail: arieh.markel@sun.COM Broomfield, CO 80021http://blogs.sun.com/arieh Phone: (303) 272-8547 x78547
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!