Re: Mirgratable or Not to be migratable - In Production JMS
Server ??

Hi,

Here are some quick thoughts.   I advise also getting advice from people that
are quite familiar with your application as well as with WebLogic "service
migration" and "whole server migration".   

-- We have some folks that plan to release white-paper on 'automatic service
migration' sometime in the next few weeks or months.

-- Only version 10.3, which is still in beta, provides automatic JMS server
migration, while automatic whole server migration is available in previous
releases.   Previous versions require that JMS server migration be initiated
manually via the console, a program, or a WLST script.   Some customers have
tied in their own HA frameworks (such as Veritas, or even home grown scripts) to
the WebLogic health monitoring subsystem to automatically respond to problems
and initiate the manual migration.

-- JMS servers that use the "default file store" cannot use service
migration - they must instead use a custom file store that is also setup to use
service migration.

-- In all cases you need to ensure that any file based persistent storage is
available on both the original machine and the target machine.    This applies
to "custom file stores", as often also the "default file
store".    

-- The "default file store" is the only place that  transaction log
data is stored, so if your app has no XA (JTA) transactions, then it absolutely
must be replicated/centralized in some way - keep in mind that some services may
use XA *internally* even if the application doesn't use XA directly (both JMS
messaging bridges and distributed destinations can use XA).

-- Even in 10.3, I think that the ALSB product (a message bus product which runs
on top of WebLogic server) and "reliable web-services over JMS or SAF"
(a feature included with WebLogic server) do not necessarily support service
migration, and only support whole server migration.   There may be cases where
they do, but I'd need to research to find out.

-- If you got past the previous bullets, then the next choice is between
"automatic whole server migration" (not the same as service migration)
 and "automatic service migration".    The former is often much easier
to configure, so if it provides fast enough restart times for your purposes,
then I recommend using whole server migration rather than service migration.