This is a little tangent, but I currently use IDS server (www.idssoftware.com) as my JDBC server, and when the DB crashes, once the DB is back up, IDS hands out connections perfectly as if nothing happened. If you don't have a good JDBC server, I feel that IDS Server was the best $1000 I ever spent in the tech industry. Robust, speedy, scalable, etc... Michael, the only guy I have talked to on tech support is INCREDIBLY helpful!
I am having the same problem. Were you able to find a solution to it, other than replacing the JDBC driver?
> Hi there,
> we're actuallly trying to make our whole system able
> to recover in case of crash.
> Up to now we've been focussing mainly on the DB
> But we just faced a this simple issue:
> the application server's connection pooling system is
> probably not able to recover after a DB crash.
> It needs to be rebooted.
> Is that true? And in this case what to do?
> Some scripting testing DB server availability by
> doing ping or something? That would really be a woe
> Any help welcome!
The problem is basically made difficult by the lack of reasonable standard exceptions from jdbc drivers. All they can do is throw sql exceptions, and you can't tell if it means a unique constraint violation or the db server disks all melted in a db independent manner.
The best solution I have thought of so far is to write db specific jca wrappers for each database that can interpret the sql exceptions and use the somewhat better designed jca error notification system to kill connections that report fatal errors.
If you did this, then when the db server crashed, each exisiting connection would report a fatal error to the application and be removed from the pool. When the db recovered, new connection requests would get new, presumably working, connections.
The new jca wrappers in jboss 3/4 are designed to make such extensions easy, but so far no one has written a db specific extension.
Are there any docs on this?
probably not, but docs on what specifically?
it starts to make some sense now. I have looked through the sources, and I think that what I should do is:
1. extend XAManagedConnection, and make checkException broadcast an error when a "fatal" exception occurs, such as in the case of a DB crash.
2. extend XAManagedConnectionFactory and make createManagedConnection wrap the connection in MyXAManagedConnection.
3. modify ra.xml in jboss-xa.jar to use MyXAManagedConnectionFactory.
There might be some details I missed, but I think that's the big picture, isn't it?
Exactly. I suggest naming the stuff VendorManagedConnection and VendorManagedConnectionFactory. If you are more ambitious you can also implement VendorXAResource to work around whatever misinterpretations of the xa spec your particular vendor indulges in. (forgive my cynicism, but so far they pretty much all seem to have incompatible interpretations)
I would REALLY like to get such extensions for each major vendor available from jboss, so I hope you will consider contributing what you come up with.
Keep in touch,