>
> In my stategy (connection pool size limit is really
> meant to be a limit), the 2000 users will queue up
> on the connection pool and the database will continue
> to work stable at it's maximum throughput.
This makes sense. I concede :-). I will remove the queue size limit. It
does seem arbitrary to me now. Though I am still leaving the timeout for
waiting in the queue. Totally deadlocking the application still does not
look like a good idea.
Also examining PoolManager.getConnection some more, I think it needs more
attention. There may still be synchronization issues. I frankly don't see
any flaws with RequestQueue. Basically in the competition for shared
resource it favors those who waited longer, as opposed to notifyAll()
mechanism that is unpredictable (and JVM implementation dependent). I
seems like the maximum time spent in the queue by any given thread should
be lower compared to a complete random scheduling (an equation, anyone ?
;-)). But I still have doubts about the way it is called in the context of
"getConnection". Your stress testing cliet may help in testing this.
>
> > The worst thing I have to deal with in one of my
> > current applications is debugging objects waiting
> > forever to get hold of a connection.
>
>
> So you are worried about deadlocks, and yes, I also
> saw a deadlock related to the connection-pool-size
> limit:
>
> If you set the limit to 1, run an iterated query,
> and while looping on it's result, run another query,
> then you get a deadlock.
>
> To understand that, go back to our discussion some
> weeks ago:
>
> http://objectstyle.org/cayenne/lists/cayenne-user/2003/02/0099.html
>
> Seems that the deeper reason while your connection-poolisize
> limit provokes deadlocks is that you use 2 connections from
> one thread.
Hmm... good point. Another thing to test... As for the original discussion
(link above), I think there are issues with reusing the connection while
there are open ResultSets, unread CLOBs, etc... The best way to see if
this is true is to actually try it out, I guess.
>
> So I'm afraid we are at bugcount=2 for the connection poolsize
> limit :-)
I will make sure this is all filed as bugs, so that we can keep a better
track of things...
Andrus
This archive was generated by hypermail 2.0.0 : Sat Apr 26 2003 - 15:05:04 EDT