Re: webapp design: how to handle connection pooling

2000-08-10 Thread Dave Smith
Connections obtained through a datasource ar closed to indicate that they are available for re-use. The actual underlying connection to the database is not closed. Joe Peer wrote: > Hi everybody, > > thank you for your responses! > > i forgot to say that i am already using orion's connection poo

RE: webapp design: how to handle connection pooling

2000-08-10 Thread J.T. Wenting
oen T. Wenting [EMAIL PROTECTED] Murphy was wrong, things that can't go wrong will anyway > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Joe Peer > Sent: Thursday, August 10, 2000 09:21 > To: Orion-Interest > Subject: Re:

RE: webapp design: how to handle connection pooling

2000-08-10 Thread J.T. Wenting
> > Option 2 is better when you are dealing with application servers, > especialy > with Orion. Orion has a very easy built-in connection pooling capability. > > When you suggest this method, I assume you are talking about an Orion > specific mechanism correct? This is convenient if Orion is the

Re: webapp design: how to handle connection pooling

2000-08-10 Thread Joe Peer
Hi everybody, thank you for your responses! i forgot to say that i am already using orion's connection pooling capability (i never thought i would give up my old connection pooling package, but orion made it possible ;=) the reason why i wrote the original message to this list was that i knew i

RE: webapp design: how to handle connection pooling

2000-08-09 Thread Kit Cragin
> This is VERY slow, and in some tests its 100's of times slower than implementing a connection pool. For the original sender (and Conrad if you are not aware of this), there are two methods I would choose over the others above. The first is connection pooling. Servlets in the same web app maintai

RE: webapp design: how to handle connection pooling

2000-08-09 Thread Keven Duffey
My input follows: > > * some people say, it's best practice to put 1 connection > > into 1 user's http > > session and use it for all requests of that user > This only works if you don't have a lot of users concurrently, > say a small intranet application, that doesn't care scalibility. > The rea

RE: webapp design: how to handle connection pooling

2000-08-09 Thread Conrad Chan
Here is my input on this interesting topic. > * some people say, it's best practice to put 1 connection > into 1 user's http > session and use it for all requests of that user This only works if you don't have a lot of users concurrently, say a small intranet application, that doesn't care scal

Re: webapp design: how to handle connection pooling

2000-08-09 Thread Subrahmanyam Allamaraju
> * some people say, it's best practice to put 1 connection into 1 > user's http > session and use it for all requests of that user This should not be done because you end up having one connection/session. Moreover connection objects are not serializable. > * other people say it's best practic