All of the solutions, except for resetting the datasourcelife,
require some server side monitoring.
I haven't done it, but in theory this should work. If you check for
<@error number1=113> and set a value somewhere, you could run a
cronjob to check for the value and restart the server if necessary.
You might be able to monitor your logs for the same error and restart
the server then.
We use a cron that executes a witango app that has a single db call
(something like select 'x' from dual) and returns an error if it
fails. We decided not to be specific about the error. If the app
gets any error, we restart the server. Of course the downside to this
is that it looks like your witango server is acting up if your
database server is unavailable for some reason. We found that most of
our production db connectivity errors were this one so it hasn't
really been an issue.
I wish I could be more help, but frankly we've pretty much given up
making this better. We've got our duct tape and bailing wire solution
that will hopefully hold out until we can replace it with something
more stable.
-sh
On Oct 13, 2008, at 1:18 PM, MC Tay wrote:
Thank you Shannon for your tips. How do I trap 113 error and
restart the Witango programmatically? Is it on the Witango side?
When we have both the app and db on the same server, it works fine.
You are right, the problem with the remote db connection could due
to firewall, drop packet etc.
MC
At 09:36 AM 10/13/2008, you wrote:
It's a known issue, and it is not specific to Oracle. We've seen
the same error frequently for Filemaker JDBC and Oracle
connections for a couple of years now. The best solution anyone
has come up with is to trap the error and then issue a restart to
the server process. There does not appear to be an easy way to
kill off the specific connection.
It appears that the error occurs when the database connection is
not properly closed, usually due to some networking interference
(dropped packets, firewall killing idle connections, etc.) We were
able to reduce the number of failures by eliminating some of the
potential points of networking failure between servers A and B. If
your database server is remote, this may not be an option for you.
The other thing we did was make sure the DATASOURCELIFE was set to
be shorter than likely network timeouts. This created a separate
problem in Oracle 9+ where idle sessions were left on the Oracle
side, eventually using up all of the available users and
significantly annoying our dba, so we ended up scheduling witango
server restarts anyway to clear those.
Depending on your setup, namely the number of connections and the
amount of site traffic you're talking about, you can try trapping
the 113 error and then setting the DATASOURCELIFE to 0,
immediately hitting the same db connection again (to timeout the
datasource). Then you reset the DATASOURCELIFE to it's previous
setting. That should force the connection to be retried the third
time most of the time. This works pretty well in our dev
environment, but it turned out to be impractical with the sheer
number of connections we work with in production.
A couple of people have contacted me on and off list saying
they've had the same issues, so I'm sure a few of us would be
happy to hear of a better solution should you come across one.
--sh
On Oct 13, 2008, at 12:55 AM, MC Tay wrote:
Hi:
I have encountering lost database connection and need some help.
I have a Witango application (Server A) accessing Oracle database
(Server B) on a remote site. It works fine not until may be 2-3
hours later the database connection is lost. I have to restart
Witango service on Server A and it works again. But, few hours
later the database connection is lost again.
Any idea how to fix this and is it a known problem?
Thanks!
MC
____________________________________________________________________
____
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
_____________________________________________________________________
___
TO UNSUBSCRIBE: Go to
http://www.witango.com/developer/maillist.taf
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
