RE: How are you handlingDistributedAccessExceptions?

Question

Hi,
It is a very interesting experiment!
About your question. I think it depends on how you code your transaction.
According to the manual, a transaction will rollback if an exception occurs
and is being handled outside that transaction. Thus, in your situation, if
the DistributedAccessException is being handled within the transaction, the
transaction isn't being rolled back yet! Therefore, when things resume
normal, you can continue.
Regards,
Peter Sham.
-----Original Message-----
From: Martin G Nystrom [SMTP:[email protected]]
Sent: Friday, March 12, 1999 11:37 PM
To: [email protected]
Subject: How are you handling DistributedAccessExceptions?
We have been experiencing network "gaps" where we get broadcast
storms and it
causes a temporary network loss for the end user. We use a pattern
whereby a
central client service object updates via remote "persistence"
service objects
to persist data.
I've done some testing by disconnecting my own network cable before
I try a
"save" (which commits the data to the persistence mgr). My custom
exception
handler catches the DistributedAccessException, and displays, "Sorry
the
network was down, try again". Then I reconnect the cable, dismiss
the
"network down" dialog, and find that the transaction completes on
its own.
I wonder... can I always be assured that the transaction will
complete once
the network is available again? When would a user need to try the
transaction
again?
-Martin
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Answer 1

Hi,
I have a different understanding, which is slightly different from yours and
the difference is on the last exception handling clause for the big
transaction. My understanding is, if I handle the exception before the "end
transaction" just like the way the exception is being handled in the middle
operation, the transaction will still commit. That's why, I usually handled
the exception outside the begin/end transaction block.
Maybe I should do some experiment on this new findings.
Peter Sham.
-----Original Message-----
From: [email protected] [SMTP:[email protected]]
Sent: Monday, March 15, 1999 11:46 AM
To: [email protected]; [email protected]
Subject: RE: How are you handling
DistributedAccessExceptions?
You can also put operations you dont want to blow the overriding
transaction inside their own exception blocks as long as you dont use the
"begin transaction" keyword..
i.e.,
begin transaction
doSomethingImportant(); // if this raises, we raise to
bottom of the big block and blow trans
begin
doSomethingLessImportant();
exception
when e : GenericException do
log the exception, clear error stack, etc..
If we hit here it will still do the next
step below in the big trans
end;
doAnotherImportantThing(); // exception here will also
raise out and blow transaction
exception
when e : ....
end transaction;
My understanding is that the middle operation is part of the
transaction, and if the third operation raises something and the transaction
rolls back the second operation rolls back also. By adding the mini
begin/exception/end block around the second operation you have simply
avoided blowing the transaction if the middle operation fails. Note that
you could also FORCE the transaction to fail if the error coming out of the
middle operation is severe enough-Just dont handle the raised exception or
re-raise something.
Hope this helps..
-Greg
> -----Original Message-----
> From: [email protected]
<mailto:[email protected]> [SMTP:[email protected]]
<mailto:[SMTP:[email protected]</a>]>
> Sent: Saturday, March 13, 1999 8:13 PM
> To: [email protected]
<mailto:[email protected]>
> Subject: RE: How are you handling
DistributedAccessExceptions?
>
>
>
>
> Forte rolls back the transaction before the exception
handler is invoked
> even if the exception is being handled inside the
transaction block. You
> should put the transaction block inside a loop and restart
the transaction
> if there is an exception or exit the loop if the
transaction completes
> successfuly.
>
>
>
>
>
>
> "Peter Sham (HTHK - Assistant Manager - Software
Development, IITB)"
> <[email protected] <mailto:[email protected]> > on 03/12/99
08:50:07 PM
>
> Please respond to "Peter Sham (HTHK - Assistant Manager -
Software
> Development, IITB)" <[email protected]
<mailto:[email protected]> >
>
> To: Martin G Nystrom <[email protected]
<mailto:[email protected]> >
> cc: [email protected]
<mailto:[email protected]> (bcc: Hetal Badheka/Blythe-Nelson)
> Subject: RE: How are you handling
DistributedAccessExceptions?
>
>
>
>
> Hi,
> It is a very interesting experiment!
> About your question. I think it depends on how you code
your transaction.
> According to the manual, a transaction will rollback if an
exception
> occurs
> and is being handled outside that transaction. Thus, in
your situation,
> if
> the DistributedAccessException is being handled within the
transaction,
> the
> transaction isn't being rolled back yet! Therefore, when
things resume
> normal, you can continue.
> Regards,
> Peter Sham.
> -----Original Message-----
> From: Martin G Nystrom
[SMTP:[email protected]] <mailto:[SMTP:[email protected]</a>]>
> Sent: Friday, March 12, 1999 11:37 PM
> To: [email protected]
<
"mailto:[email protected]">mailto:[email protected]>
> Subject: How are you handling
DistributedAccessExceptions?
> We have been experiencing network "gaps" where we get
broadcast
> storms and it
> causes a temporary network loss for the end user. We
use a pattern
> whereby a
> central client service object updates via remote
"persistence"
> service objects
> to persist data.
> I've done some testing by disconnecting my own
network cable before
> I try a
> "save" (which commits the data to the persistence
mgr). My custom
> exception
> handler catches the DistributedAccessException, and
displays, "Sorry
> the
> network was down, try again". Then I reconnect the
cable, dismiss
> the
> "network down" dialog, and find that the transaction
completes on
> its own.
> I wonder... can I always be assured that the
transaction will
> complete once
> the network is available again? When would a user
need to try the
> transaction
> again?
> -Martin
>
> -
> To unsubscribe, email '[email protected]' with
> 'unsubscribe forte-users' as the body of the message.
> Searchable thread archive
> <URL:http://pinehurst.sageit.com/listarchive/
<URL:http://pinehurst.sageit.com/listarchive/> >
> -
> To unsubscribe, email '[email protected]' with
> 'unsubscribe forte-users' as the body of the message.
> Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/
<URL:http://pinehurst.sageit.com/listarchive/> >
>
>
>
>
>
>
> -
> To unsubscribe, email '[email protected]' with
> 'unsubscribe forte-users' as the body of the message.
> Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/
<URL:http://pinehurst.sageit.com/listarchive/> >
To unsubscribe, email '[email protected]' with 'unsubscribe
forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/
<URL:http://pinehurst.sageit.com/listarchive/> >
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>