Hi Arieh,
I haven't run any experiments but I would expect that you would have to
be careful about how you commit this work. If one thread commits the
connection while another thread is in the middle of a statement, someone
is likely to be disappointed.
You will likely have deadlock issues if you try to scale your
application by running two teams of threads, each working on its own
connection.
Regards,
-Rick
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 ?
Thanks,
Arieh
PS: please, reply directly, as I am not in the aliases ...
