It's sounding horrible like no tests are being made with regard to whether the WRITE can be completed until it hits the TRANSEND - in which case the TRANSEND is failing without indicating which of the previous writes it was failing to complete.
I guess in some ways this would be logical (though not necessarily correct!) as all updates would be queued in memory until you hit the TRANSEND.... No help but maybe a reason why it's doing this.. Simon -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 30 April 2009 12:42 To: jBASE Subject: Re: Transaction Boundaries Problem Bruce, If this is an urgent issue. I suggest that you contact [email protected], ASAP. Rick On Apr 30, 12:47 am, Bruce Willmore <[email protected]> wrote: > Hi again, group. I apologize if I might seem impatient. I'm just > taking heat for trying to utilize transaction boundaries in my > application when they are behaving in this fashion. I really need some > help.... Thanks. > > On Apr 29, 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 - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Simon Verona.vcf
Description: Binary data
