Dive into Oracle ADF

Send me a mail
 Dive into Oracle ADF   Click to see the XML version of this web page.   (Updated: 2/3/2008; 8:11:49 PM.)
Tips and tricks from Steve Muench on Oracle ADF Framework and JDeveloper IDE

Search blog with Google:
 

Search BC4J JavaDoc:
 

February 2003
Sun Mon Tue Wed Thu Fri Sat
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28  
Jan   Mar

Get Firefox!

Wednesday, February 12, 2003

What is BC4J "Failover Mode"?

Our documentation describes how to turn the failover feature of the application module pool on or off, and it suggests that leaving it off can give your application more performance, at the cost of not being able to withstand an application server or database failure. However, we don't really go into detail about what the failover feature is doing for you under the covers.

First off, the failover mode only is relevant to application modules that you are using in the "Stateful" mode. "Stateless" application modules won't have any pending state to preserve across multiple requests in a session. Remember that our "Stateful" mode gives performance and resource utilization close to that of a purely stateless application, but with the programming convenience of a stateful paradigm -- without having to invent a custom scheme for remembering pending changes that are not yet ready to commit to your real application database tables.

In a nutshell, turning failover mode on (jbo.dofailover=true) requests that the BC4J application module pool store a snapshot of the pending middle-tier state to the database each time the AM is released to the pool by a client. In a web application using a release mode of "Stateful", this means that you will visit the database on each page request to make sure that you've stored the pending  state of the application module. The state management data written to the database happens using a secondary pool of database connections whose login details you can control using the jbo.server.internal_connection property (in order to cleanly separate the state management info from your application tables/schema).

If the application server is stopped and started, or the next request is routed to a different application server, or if the database is shutdown and startup, on the next successfully handled HTTP request with the database available, the previous pending state from the application module will be reloaded from the database and the user can keep going where they left off. So using the failover option makes your application more resilient at the price of a database round-trip over the "internal connection" on each request.

If this type of failover capability is not required, you can turn the feature off. With failover off, the pending state of an application module is written out to the database only when absolutely necessary. This would occur if your application pool size was not large enough to handle your incoming HTTP request load, causing the application module pool to be forced to reassign an existing AM instance in the pool to a different user session that the one who last used it and put it back in the pool in "Stateful" mode.


7:38:21 AM    



© Copyright 2008 Steve Muench.