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]
