If you are taking heat for using transaction boundaries my question would be "Is everything encompassed within the transaction critical to the transaction?" If it isn't then move part of it out of the transaction. If it is then you MUST use transactions.
Dick On Thu, Apr 30, 2009 at 7: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. >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
