connection issues could sometimes be hard to solve for a middleware
administrator. Below are three scenarios that we have run into, and that
are easy to check, now that you know about them:
Initial connection pool When
you configure a connection pool in WebLogic (from 10.3.6/12.1) you can
set Initial Capacity. Initial Capacity is the number of physical
connections to create when creating the connection pool in the data
source. Depending on your application(s) you might be tempted to set
this to a high value, but be aware of at least two issues.
- It takes longer time to start your WebLogic server (but since you rarely restarts the server that might not be an issue)
for some reason your WebLogic server can’t reach your database server,
your WebLogic server never reaches RUNNING state, but stops at ADMIN
state. Of course your database server should be available all the time
(in theory), but if both your database server and WebLogic server have
been down in the maintenance window, and your WebLogic server boots
faster than the database server, you are out of luck.
Missing test table You
can enable Test Connections on Reserve (Advanced option on the
Connection Pool tab). If you do that, you have to provide a Test Table
Name (or a SQL, more about that below). The default SQL code used to
test a connection is “select count(*) from TestTableName”. So what
happens when someone cleans up the database and accidentally deletes the
test table. Well, the SQL will fail, and your connection pool will
after a while not have any valid connections.
One way to avoid
this is to provide a SQL instead of just a table name, to override the
default SQL. If you provide SQL SELECT 1 FROM DUAL you should always get
a sane reply from the database, as long as it is up and running.
Your not so friendly neighbourhood firewall Servers
usually expects tcp keepalive to be two hours, which means that a tcp
connection could be idle for two hours before it is considered idle, or
before a keep alive packet is sent. Unfortunately most firewalls thinks
that one hour is more then enough and drops idle tcp connections after
3600 seconds. Even more unfortunately firewalls tends to just drop
packets for closed connections, instead of sending a reject message back
(for a firewall facing external traffic it makes sense to drop
forbidden packets coming from internet, but for internal traffic a
reject would have solved many issues).
The result is that after a
low traffic period, i.e. during a night, weekend or a public holiday,
you have a connection pool full of connections that doesn’t work. Read the complete article here.
WebLogic Partner Community
For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.
Blog Twitter LinkedIn Mix Forum Wiki