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
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 only
. 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: webapp design: how to handle connection
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 pooling
* 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 practice
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
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 reason is
