That always seemed just "/*wrong*/" to me! I could never figure out why
a connection pool license would work this way. Sure puts a crimp on a
number of potentialities. :-)
Bill
------------------------------------------------------------------------
----- Original Message -----
*From:* syme...@gmail.com
*To:* 'U2 Users List' <u2-users@listserver.u2ug.org>
*Date:* 12/1/2011 11:52 AM
*Subject:* Re: [U2] Unidata 7.1 Unresponsive UO Connection
A pooling connection goes into 1 single account yes
We have a special "shared" account for the pools with voc pointers to the
real customer accounts . Part of the message passed to the backend is the
customer so it opens the correct files etc.
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: 01 December 2011 17:41
To: U2 Users List
Subject: Re: [U2] Unidata 7.1 Unresponsive UO Connection
Symeon:
Your "pooling" connection is set up for a single dbms account, correct?
You'd need a separate "pooling" license for each dbms account to access,
correct?
That is some dance you need to go through to do what, basically, the
computer is supposed to do!
Bill
------------------------------------------------------------------------
----- Original Message -----
*From:* syme...@gmail.com
*To:* 'U2 Users List'<u2-users@listserver.u2ug.org>
*Date:* 12/1/2011 8:36 AM
*Subject:* Re: [U2] Unidata 7.1 Unresponsive UO Connection
Similarly here - I have two web services that my apps connect to - one
is pooled, the other not. Typical time for a transaction using the
pooled one is between 300 and 600 ms, whereas the non pooled for the
same transaction is between 1 and 2.
I have 2 because my apps connect to the pooled web service with a 2
second timeout, then fail over to the non pooled. I have to do this
cos the pooled connections hang several times a day (hence why I have
to restart unirpcd and kill off the pooled udt processes) The problem
is not in the DB code as it happens randomly and with our logging it
is definitely coming out of the DB code and then refuses to accept any
more data on the socket, and the .net code is very simple, so it must
be in the uniobjects layer or unirpcd. I have tried several dll's to no
avail, so we will have to get a new linux box
with the very latest udt and see how that goes. Long sigh .....
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Holt, Jake
Sent: 01 December 2011 15:12
To: U2 Users List
Subject: Re: [U2] Unidata 7.1 Unresponsive UO Connection
Did you do any actual testing on that to confirm it? I created a WCF
web service that manages a set of shared connections for all of my
.net apps that access UniVerse. I found that starting the session
took much longer then processing most of my requests if the session was
already open.
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Wednesday, November 30, 2011 8:00 PM
To: U2 Users List
Subject: Re: [U2] Unidata 7.1 Unresponsive UO Connection
Not focusing on connection pooling at this point but that may be a
consideration for the future. I've found that the overhead of the two
Apache method is so small that most of the gains offered by connection
pooling are minimized.
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
