Simon Verona wrote: > 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.... > Which is of course what it does. It is correct because with the HASH files, there is no good way to pre-update the records without overhead on other reads. We did discuss scenarios.
The other way to do it involves an isolation level of READ-UNCOMMITTED. Because of the way in which MV applications are designed, this is generally not workable for most. The essential 'problem' is that locks are taken by the application only when updating and so events like SELECT READNEXT cannot be guarded from yet to be committed updates. Catch 22 really. Cache uses READ UNCOMMITTED (basically, back out of the transaction if something bad happens, and just mark it as good when it does not. There are application design ramifications of course, as otherwise your application is by-passing atomicity. Jim --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
