Technically speaking the EJB container on the other machine (the
failover one), can recreate your entity and automatically load it, since
it knows what primary key to use.
But if you are running inside a transaction a failure will always
rollback and cancel all your entities. A failure is regarded as either
server falling down or the entity bean dying out with some runtime
exception.
Both case can potentially cause inconsistency in the database or entity
(or other beans), and since there's no AI to track these
inconsistencies, the transaction will be rolledback.
If, however, the container just crashes while you're not in the middle
of a transaction, you can refine the entity beans on a different server
without a problem (same with stateless sessions).
arkin
dan benanav wrote:
>
> So my understanding from this is that it does not provide automatic failover as in
>the case of stateless beans. That is when you invoke a method on the entity remote
>object an exception will be generated if the server is down. The application
>programmer must handle that condition by doing another findByPrimarykey on the home
>object. How can you tell that a RemoteException is caused by a server failure?
>
> I would like to see automatic failoever provided by the entity bean.
>
> dan
>
> Eyal Hirsch wrote:
>
> > Hi Dan,
> > <vendor>
> > Take a look at the following address for how Inprise in
> > Inprise Application Server 4 implements what you need :
> >
>http://www.borland.com/devsupport/appserver/faq/Availability_Scalability_Performance.html
> >
> > This is from the document there :
> >
> > Failover is supported by leveraging the Naming Service and the osagent. We support
>failover of all types of EJBs. To summarize the behavior:
> >
> > 2) Entity Beans. From the Container standpoint, Entity Beans are similar to
>Stateless Session Beans, except that before being able to use a replica entity, it
>needs to be loaded in. The current transaction will fail, as it should. Both the
>resource and the synchronization objects associated with the original (failed) entity
>in VM 1 will be unavailable, and the transaction manager, presuming rollback (as per
>the OTS/JTS specification) will roll back the current transaction. However,
>subsequent transactions will simply fail-over to use the replica entity in VM 2, and
>will continue correctly.
> >
> > </vendor>
> >
> > eyal.
> >
> > ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
