well u can always call the remote service/method a number of times in case
u get a remote exception -- but the fact u have to consider is -- whether
the method/service u are calling is idempotent or not. It may happen that ur
request has actually been seviced and commited -- and the server/service
crashed before returning. In that case though ur request has been serviced
the client gets a remote exception. So if the client calls again then the
action will be performed twice. So if u are going for that particular design
-- do make ur service idempotent.
BTW is there any genric rule/way to make service idempotent?
TIA
Anamitra

-----Original Message-----
From: David Van Couvering
To: [EMAIL PROTECTED]
Sent: 8/18/00 7:03 PM
Subject: Re: Using Dynamic Proxies for Fault Tolerance

>From what I understand you *can* throw RemoteException in an
implementation
method, you just don't *have* to.

The other thing you can do is re-throw the RemoteException as an
EJBException...

Dynamic proxies are great, I would definitely give them a shot.

David

> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook
> Sent: Thursday, August 17, 2000 7:41 AM
> To: [EMAIL PROTECTED]
> Subject: Using Dynamic Proxies for Fault Tolerance
>
>
> I could use some advice on a pattern to use to enable fault
> tolerance on the
> client-side of the EJB scenario. My clients access session beans
through a
> Facade (FundBroker) interface that is implemented on my client by
> a class named
> FundBrokerImpl.
>
> If the client invokes a method in FundBrokerImpl, the method
> simply makes the
> call against the appropriate session bean. If I receive a remote
> exception, I
> attempt to resubmit the request a number of times before trying
> more drastic
> actions. I understand that I could put the following code in all
> of my methods:
>
> while (attempts < 3) {
>     try {
>         remote.getSomeValue();
>         return;
>     } catch (RemoteException rx) {
>         attempts++;
>     }
> }
> // handle fatal error
>
> I want to use Dynamic Proxies in JDK 1.3 to leverage the proxy
> pattern so I can
> eliminate some of the monotonous coding. I also want to eliminate
> the client
> (but not this proxy) from dealing with any extreme fatal errors.
> Therefore, one
> stipulation that I have is that the method signature in
> FundBroker cannot throw
> a RemoteException.
>
> FundBroker:     Value getSomeValue();
>
> The problem is that the method signature in the implementation
> class also cannot
> throw RemoteException. Unfortunately, this method will contain
> the call to the
> remote ejb interface, which most certainly *will* throw
> RemoteException. Of
> course, the compiler won't let this conflict pass unnoticed.
>
> I know of several ways to get around this pattern without
> resorting to Dynamic
> Proxies, but I was wondering if anyone can think of a way I can
> use this very
> cool feature.
>
> thanks,
> jim
>
> ==================================================================
> =========
> 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".


STATEMENT OF CONFIDENTIALITY.   The information contained in this electronic
message and any attachments to this message are intended for the exclusive
use of the addressee(s) and may contain confidential or privileged
information. If you are not the intended recipient, please notify
USPowerSolutions Corporation immediately at (617) 547-3800, or at
[EMAIL PROTECTED], and destroy all copies of this message and any
attachments.

===========================================================================
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".

Reply via email to