db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Clausen ...@statsbiblioteket.dk>
Subject Re: Concurrency in connections and Threads
Date Thu, 10 Nov 2005 16:49:31 GMT
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 wanted to bring up the scenario.

> 
> Now if you think about it, why would a database engine want to manage multiple 
> transactions per connection? Keep in mind that you don't want to create a 
> situation where you have nested transactions. (This would get ugly fast) So 
> you would have to implement this in a manner that 
> 
> From a design perspective, do the potential benefits outweigh the development 
> costs? In this case, I'm not sure.

Which reminds me:  We're currently doing our own very small connection
pool (basically one connection per thread) exactly to avoid these kinds
of problems.  Does Derby connection pooling say anything about what
happens with multiple threads?  Or is there some other way to ensure
connection-per-thread?

> Can anyone provide an example where the cost of opening a connection is too 
> expensive and that implementing multiple transactions in a single thread is 
> better?

Supposedly for connecting to network servers.

> As a side note, this would actually be a good use of Derby. To allow for 
> easier exploration of potential advancements in DB theory. 
> 
> To do this problem, you'd also have to extend the SQL language a little.
> 
> But hey, what do I know? The mind doesn't start to function until after the 
> 2nd slice of pizza and the third beer. ;-)

Indeed.  Where's mine?

-Lars


Mime
View raw message