Yong, For an application to realy benifit rac, the developers have to make it aware of fan. There are some prerequisites on the java classes to be used and statements should be retried when a failover happens. To be scalable on rac the application should also be "functional partitioned" so different modules of the application can be pointed to different nodes (instead of just load balancing everything). And last but not least, the application should be performance tested on rac. Executing a lot of queries each doing full table scans, makes rac very unhappy So yes, if you want your application not just to run on rac, but also really benefit from it and have good performance, then the developers should develop with rac in their minds. (and not use Hibernate) Regards, Freek D'Hooge Uptime Oracle Database Administrator email: freek.dhooge@xxxxxxxxx tel +32(0)3 451 23 82 http://www.uptime.be disclaimer: www.uptime.be/disclaimer -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Yong Huang Sent: woensdag 19 mei 2010 5:14 To: Tony Adolph Cc: oracle-l@xxxxxxxxxxxxx Subject: Re: Documentation for reasons to NOT use RAC? > > I don't see how developers should write code differently >> if the code needs to be deployed to RAC.: > > Its not just being TAF/FAN aware, see Gints Plivna's comments > earlier in this thread. Tony, I understand Gints Plivna's and kathy duret's responses at //www.freelists.org/post/oracle-l/Documentation-for-reasons-to-NOT-use-RAC,23 They both proposed great ideas for application server admins. The only thing developers should do a little differently is perhaps "Use of parallel in queries to take advantage of the Rac power", but that's not really RAC-specific. In short, the developers don't need to do anything special for RAC. DBAs and mid-tier administrators do. Yong Huang -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l