I agree, if three attempts fail I can try to get more agressive in my attempts.
I suppose I'll just have to put a facade between the client and my wrappered
(dyn. proxy) stub to eliminate the countless try/catch blocks.
jim
----- Original Message -----
From: "Bhattacharyya, Ana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 20, 2000 8:45 PM
Subject: Re: Using Dynamic Proxies for Fault Tolerance
> 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".
>
>
===========================================================================
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".
