Hi again, each thread have to use it's on PB instance --> different connections
Normally the steps are: 0. get PB instance from pool (1 - PB Creation) 2 - PB beginTransation 3 - PB store 4 - PB commitTransaction 5. do PB.close() in finally block to return PB instance back to pool. regards, Armin ----- Original Message ----- From: "Pierfranco Lai" <[EMAIL PROTECTED]> To: "'OJB Users List'" <[EMAIL PROTECTED]> Sent: Wednesday, May 28, 2003 7:18 PM Subject: R: OJB System Test ISSUES Hi Armin, > -----Messaggio originale----- > Da: Armin Waibel [mailto:[EMAIL PROTECTED] > Inviato: mercoledì 28 maggio 2003 18.45 > A: OJB Users List > Oggetto: Re: OJB System Test ISSUES > > > Hi Pier, > > ----- Original Message ----- > From: "Pierfranco Lai" <[EMAIL PROTECTED]> > To: "'OJB Users List'" <[EMAIL PROTECTED]> > Sent: Wednesday, May 28, 2003 6:02 PM > Subject: OJB System Test ISSUES > > > > > > I've developed a application with Struts, OJB rc3, Oracle App Serv > OC4J 903 > > and Oracle 8 DB. > > > > Now I'm stress-testing the application with JMeter: 5 > concurrent users > with > > 3 different http request. > > > > Some questions: > > > > 1) > > It seems that the begin, commit and abort transaction funct have > effect to > > all the connections of the pool of the PB. > How does it effect all connections? Suppose you have 2 simultaneous threas (two users performing the same INSERT). Normally the steps are: 1 - PB Creation 2 - PB beginTransation 3 - PB store 4 - PB commitTransaction 4.1 - Exception PB abortTransaction When the first user thread perform the commitTrans, the second user get an Excpetion (ConnectionManager is NOT in transaction). > > > That's correct? > I don't hope so ;-) I don't too ;-))) > > > I've followed a previous suggestion (open a PB before the > > begin-tras and close it after the commit) but I does not work > correcly. > > OJB was shipped with a simple multithreaded test. This test > does not point out any problems. > call 'bin\build.bat perf-test' > > Do you use OJB within EJB's? > > > > > 2) > > If a connection-pool is full, how can I prevent any > operation before? > I > > mean: can I check if the broker can perform a query or an insert > before to > > do that? > (Don't know if I understand your question) > No, but you can setup different scenarios when pool is > exhausted: > - throw exception > - wait for next returned connection (recommended > only for multithreaded environments) > - grow > > regards, > Armin > > > > > Thanks > > Pier > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
