Sorry, but I have to disagree. If you have transaction boundaries enabled, then none of the exception clauses associated with writes will function. What will happen is that TRANSEND will simply fail and execute the logic associated with it's ELSE clause.
If you don't use transaction boundaries, then you no longer have atomic updates, so if there is some type of I/O failure, your code has visibility to it, but then what do you do with that information from a design perspective? If the I/O error is a write error and it occurs on anything but the first write of a transaction, then something or someone has some cleanup to do. Personally, I'd rather have transaction boundaries and be forced to do some detective work if my transaction commits start failing (although it would be nice if there was some way to be pointed in the right direction). On May 4, 8:34 am, Mike Preece <[email protected]> wrote: > If you had all of your IO going through a standard subroutine then you > could trap, record and/or return each and every error code. You could > do anything you wanted. > > On Apr 30, 2:33 pm, Bruce Willmore <[email protected]> wrote: > > > > > Thanks, Dan. > > > The more that I thought about it last night, the more that I realized > > what the answer was going to be, and it makes perfect sense, although > > it sure would be nice if TRANSEND could throw some kind of indicator > > as to what transpired. Maybe a suggestion for a future release... :-) > > > I sincerely appreciate everybody's assistance in this, and I apologize > > if I might've seemed a bit "panicky" earlier. This is a high-profile > > application, and I was starting to get that "deer in the headlights" > > feeling from the questioning that was starting to occur. > > > Even though I can't trap the source of the problem within a > > Transaction Boundary, I'm still going to recommend that the > > application continue to use them, because the benefits that > > Transaction Boundaries extend far outweigh the difficulties in > > troubleshooting. > > > On Apr 30, 8:54 am, Daniel Klein <[email protected]> wrote: > > > > This is by design. The updates within the transaction boundaries are > > > treated > > > as a single update; there is no way to target why a specific update > > > failed. > > > > If you really need to know why a particular update failed, then you should > > > interrogate the permissions on the file prior to the update, or (better > > > yet) > > > perhaps when the file is initially OPEN'd by writing and deleting a > > > 'dummy' > > > record. > > > > Dan > > > > On Wed, Apr 29, 2009 at 3:17 PM, Bruce Willmore > > > <[email protected]>wrote: > > > > > Hi everyone: > > > > > I'm hoping that somebody can help me. We are running jBase 4.1.6.7 on > > > > HP/UX B.11.31 > > > > > I should also note that we are not currently using Transaction > > > > Journaling, although we do plan to shortly. > > > > > I'm going to start to describe my problem with a little code snippet: > > > > > WRITE Record ON SomeFile, ItemID SETTING ResultCode ON ERROR do > > > > something > > > > > If SomeFile happens to be read-only, then ResultCode will be set with > > > > a value indicating failure and the ON ERROR clause in the WRITE > > > > statement will get executed. > > > > > However, if the WRITE statement is defined within a Transaction > > > > Boundary such as > > > > > TRANSTART SYNC ELSE do something > > > > WRITE Record ON SomeFile,ItemID SETTING ResultCode ON ERROR do > > > > something > > > > TRANSEND ELSE do something > > > > > then the SETTING and ON ERROR clauses in the WRITE statement do not > > > > execute. The ELSE clause in the TRANSEND statement executes, which I > > > > would expect, but it does not provide any indication as to why the > > > > transaction failed; only that it did fail. > > > > > Now, I used a read-only file in my example simply because it is an > > > > easy condition to reproduce. I encountered this situation in real life > > > > with a file that got corrupted during a stress test of our QA Web > > > > Service, and the jBase backend of the service started to throw errors > > > > indicating that the TRANSEND statement had failed. Nothing more, even > > > > though all WRITEs that occur are done using SETTING and ON ERROR > > > > clauses to throw the proper error codes for the backend application to > > > > interpret. I had to investigate all of the files that are written to > > > > before finding the culprit. > > > > > On to the actual question... Is there something that we may have done > > > > in our configuration or elsewhere that is causing jBase to behave in > > > > this fashion? Is this a bug in jBase, or is this simply the designed > > > > behavior? Thank you in advance for your assistance.- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
