|
Home > Archive > WebSphere HATS > September 2005 > why connection pool stick to web session?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
why connection pool stick to web session?
|
|
| david chan 2005-09-16, 5:45 pm |
| Hi,
I am testing the connection pool, and found out once a connection pick up
from pool by one web session, it won't be reused by new web session.
Do I need to do come configuration to remove this limtation?
Because my HATS is in web services which don't support web session, and I
can't take advantage of connection pool.
I am using Websphere application server 6.0.1, HATS 6.0.2.
Connection is 3270.
Thanks.
DAvid
| |
| George Baker 2005-09-16, 8:45 pm |
| In article <dgellc$4lo6$1@news.boulder.ibm.com>, davidchantf@comcast.net
says...
> Hi,
> I am testing the connection pool, and found out once a connection pick up
> from pool by one web session, it won't be reused by new web session.
> Do I need to do come configuration to remove this limtation?
> Because my HATS is in web services which don't support web session, and I
> can't take advantage of connection pool.
> I am using Websphere application server 6.0.1, HATS 6.0.2.
> Connection is 3270.
>
> Thanks.
> DAvid
Are you using a chained integration object? If so the session will not
be reused until you run last-in-chain.
If you are not using chained integration objects, then there are many
things that must be looked at. Tell us more about how you have things
set up, like number of items in pool (minimum and maximum) are there
connect/disconnect macros and what do they do. How are you testing and
what do you observe.
| |
| david chan 2005-09-19, 5:45 pm |
| I have tested with these config in connection object:
terminate conn. after a max. idle time: 120
terminate conn. after a max. busy time: 60
min. number of idel conn . to retian in the pool: 1
max.# of conn. in the pool that can be active: 1
After the max. limit of conn. has been reached: create a new (non-ooled)
connection
I have connect/disconnect macro for the connection object.
Checkin screen: use first exit screen of the connect macro
( there is only one exit screen in my connect macro).
I tested both non-chained and chained integration object. For both I test
the marco first in host terminal, both case Marcos are run fine.
Here are my procedures:
I tested first without cookie, i.e new session for each request.
I use HttpClient to create web reqeust without cookie to the HATS
application, and I printed out the sessionId, each time is new sessionId.
The first request which is successful by using pooled connection, and it is
fast less than 1 second. Then I made second request, but second request made
the HATS create a new HATS connection. (I use netstat in windows command
line console, and it showed a new HATS connection created.)
Second test: I use Internet browser with cookie enabled:
I made two requests to the HATS application by using browser, each request
printed out with same sessionID, and no new HATS connection created. Both
request can use same pooled connection.
Thanks.
David
"George Baker" <gbaker@us.ibm.com> wrote in message
news:MPG.1d95075dfe78bd509896c5@news.software.ibm.com...
> In article <dgellc$4lo6$1@news.boulder.ibm.com>, davidchantf@comcast.net
> says...
>
> Are you using a chained integration object? If so the session will not
> be reused until you run last-in-chain.
>
> If you are not using chained integration objects, then there are many
> things that must be looked at. Tell us more about how you have things
> set up, like number of items in pool (minimum and maximum) are there
> connect/disconnect macros and what do they do. How are you testing and
> what do you observe.
| |
| George Baker 2005-09-20, 5:45 pm |
| In article <dgmfa6$36c8$1@news.boulder.ibm.com>, davidchantf@comcast.net
says...[vbcol=seagreen]
> I have tested with these config in connection object:
> terminate conn. after a max. idle time: 120
> terminate conn. after a max. busy time: 60
> min. number of idel conn . to retian in the pool: 1
> max.# of conn. in the pool that can be active: 1
> After the max. limit of conn. has been reached: create a new (non-ooled)
> connection
>
> I have connect/disconnect macro for the connection object.
> Checkin screen: use first exit screen of the connect macro
> ( there is only one exit screen in my connect macro).
>
> I tested both non-chained and chained integration object. For both I test
> the marco first in host terminal, both case Marcos are run fine.
>
> Here are my procedures:
> I tested first without cookie, i.e new session for each request.
> I use HttpClient to create web reqeust without cookie to the HATS
> application, and I printed out the sessionId, each time is new sessionId.
> The first request which is successful by using pooled connection, and it is
> fast less than 1 second. Then I made second request, but second request made
> the HATS create a new HATS connection. (I use netstat in windows command
> line console, and it showed a new HATS connection created.)
>
> Second test: I use Internet browser with cookie enabled:
> I made two requests to the HATS application by using browser, each request
> printed out with same sessionID, and no new HATS connection created. Both
> request can use same pooled connection.
>
> Thanks.
> David
> "George Baker" <gbaker@us.ibm.com> wrote in message
> news:MPG.1d95075dfe78bd509896c5@news.software.ibm.com...
It sounds like you are trying to use pooling with a Transformation
client. Pooling was not designed for a Transformation client (refer to
the InfoCenter) and will likely experience the symptoms you are
reporting. Pooling is designed for Integration Objects and Web services
where it is very efficient.
Once you start a transformation session that session is dedicated to
that specific session as set by the HTTPSessionID. If another request
comes in for the pool and the old session was not yet disconnected, then
another pool item will be created.
Sounds to me like things are working as designed.
|
|
|
|
|