Hi Steve, ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Saturday, November 16, 2002 8:23 PM Subject: running out of pb instances in pool during multithreaded test
> Maybe this has been discussed before, I did some searching thru > the list archives and couldn't find anything... > > I wrote a multithreaded unit test to test out my persistence layer. OJB shipped with a multi-thread stress test too. Call: bin\build.bat performance2 this test should pass with the OJB default configuration. >I > kick off threads and they each do the same query. When I make > the number of threads greater than the number of pb instances in > the pool, I get a NoSuchElementException thrown. Yes, this was the default behaviour. But you have a bunch of configuration properties to change this. See in OJB.properties section: PersistenceBrokerFactory pool. For example: Grow pool automatic when exhausted, block pool (not recommended, because one thread may need more then one PB instance, this could be end in deadlock), grow pool automatic and clean up idle instances,... All you describe below was possible to do - hope so ;-) The same bunch of configuration properties are possible for the connection pool. In OJB.properties you could only manage the maxConnectionsInPool. For more fine-grained control see repository.dtd element 'connection-pool'. HTH regards, Armin > > This may all be painfully obvious behavior but I guess I'm wondering > a few things: > 1) Is this in fact supposed to happen? i.e. does this mean i'm doing > something wrong or have something configured wrong? > 2) should I be the one catching the NoSuchElementException and > manually creating a new broker instance? > 3) should I just not worry about this, because a situation like this is > so unlikely in the real world (20+ simultaneous requests for a pb)? > 4) is the normal solution to this problem just to jack up the number > of pb instances in the pool to some number via the props file, and > just hope your app doesn't need more than that number of > connections at the same time? > 5) from a best practices perspective, is this the behavior you'd want > to happen? I was thinking maybe you'd have something that > sensed when the pb pool was low/empty and instanciated new > instances on the fly. Maybe that has negative ramifications. This is > an honest question asked out of ignorance: I'm not at all implying > that something different should be done. > > Regards, > Steve > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
