We are proposing to implement Oracle 9i RAC for our company's production system for a new OLTP application that is under development.
The question is:
Is it possible to implement RAC on jboss application server?
I guess the answer to it is yes.
But the uncertain thing is: During failover, TAF comes into picture, and the application will be using JDBC thin drivers or OCI for DB connections/connection pooling. I have read in Oracle documentation that connection pooling will not work with TAF.
Barring that, has anyone implemented RAC with JDBC? Or do I need to use OCI drivers?
If yes, can you kindly provide some details about the implementation?
I have also researched on a new driver called C-JDBC, but they have not actually tested on Oracle RAC...
So, if any kind-hearted DBA can provide me something to grab :-) I'll be most grateful.
what if TAF?
As far as i'm concern there is nothing to do with jdbc or connection pooling. RAC is where two or more instance running on saperate machine and sharing same storage. During failover your application should look to the other node. This is configurable at jboss at web.xml( if i'm not mistaken).
Why on earth OCP is to be proud
Well said Julian !
DBAs r supposed 2 know what TAF is !!
I am the DBA for this organization and am not very familiar with front-end like java/asp etc.,
That's the reason I am at a loss as to how application failover happens if the connection drivers (in our case JDBC/OCI) are not compatible... Moreover, TAF does not support DML, another negative..
Still, many advantages can be derived outta RAC, especially for an application like ours, where scalability and availability are priority... We r also considering Data Guard..
Originally posted by julian TAF is Transparent Application Failover
Because OCP might know what TAF is :-)
Well, OCM no need to know TAF or whatever product not frequently used. only OCP does. OCP always give comment and complaint on other people said but OCM always trying to help people by answering the given question. So that is why on earth OCM is not to be proud but OCP does. Don't understand???? you must be an OCP.
For JSP or web application to have failover you need to have your application compiled with correct OCI8 librarries.
The easiest way to demo RAC failover from one node to another is to
use a SQL*Plus session, because it is compiled with the OCI8 libraries, and TAF is pretty straight forward to set up with it.
remember stateful applications cannot be failed over.JDBC thick drivers are okay.(type 2 drivers).I think if my memory doesnt beat me u need to have THICK type drivers only for TAF.think drivers will not work for TAF
TAF has a couple of different failover modes. The default is NONE (i.e. not turned on).
You can also have it set to SESSION (fails over the session but you need to re-execute your last statement), or SELECT (Fail over the session and continue the query).
You can even set it up to have the session PRECONNECT if
you want to. One thing that you can't yet failover is DML, because it's always stateful .
My company had problems becoz of the last one where the customer thought that when we install RAC we are giving him transaction failover..and we had to cancel the contract.
metalink would be your best bet for JDBC driver and RAC certification info.
We use RAC with PeopleSoft. As PeopleSoft is not TAF aware we can't really use it. Your app has to be coded specficially to be TAF aware.
What we have found though through using server side load balancing is that failover is somewhat transparent to our users. In our config the worst that could happen is that user A submits transaction to server A, server A fails and the APP returns a message like operation failed. If the user submits the same operation again server side load balancing knows enough to direct to the live node and is able to complete the application.
We've been live for a year now and have seen this behavior once in production and thankfully over lunch. It was transaparent enough to the point where I had to tell the managers the next day that we had a failure, they had no idea and we had not one single complaint from any users and we run payroll and portal access for 80,000 users.