Hi Arieh,The situation is complicated if you run multiple statements using the same connection and don't exhaust the ResultSet before returning the connection to the pool.If all you are doing is insert/update/delete then the statements are essentially complete when they are executed. Just watch out
On Thu, 2005-11-10 at 18:42, Michael Segel wrote:
> On Thursday 10 November 2005 09:33, Arieh Markel wrote:
> Safe?
I agree in your scepticism. It said he was safe from that particular
scenario, but I don't enough to say that having autocommit on keeps him
same from other similar things. Just wa
On Thursday 10 November 2005 09:33, Arieh Markel wrote:
Safe?
Its not really a good idea to share your connection like that.
Just because you can do it, doesn't mean its a good idea. ;-)
Its possible for newer JDBC API implementations to allow for multiple
transactions per connection, but then y
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 ta
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
Arieh Markel wrote:
My assumptions are as follows:
- table lock granularity is what is in place in Derby
Are those assumptions true ?
Just wanted to point out , that by default Derby is configured for
row-level locking.
http://db.apache.org/derby/docs/10.0/manuals/develop/develop73.html#
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 i
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 aw
