the commit rollback thing

[John Esak]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Fairlight
> Sent: Friday, March 26, 2004 8:29 AM
> To: filePro mailing list
> Subject: Re: the commit rollback thing
>
>
> This public service announcement was brought to you by John Esak:
> >
> > Yes, after our FP Room conversation... I see what you were
> saying. If you
> > have a process that posts to 20 other tables... with a
> commit/rollback RDBMS
> > you can just say... roll all this stuff back near or at the end of the
> > transaction and it will be done. In filePro this requires "not"
> posting to
> > the other files until you are sure everything is the way you want it and
> > then dint the post and "commit" of everything. Yes, this is a
> big pain in
> > the ass and if there were a way not to do it... that would certainly be
> > cool. However, like I say, it _is_ possible to emulate this in
> filePro. Not
> > impossible, I do it all the time.
>
> Which point in the discussion brings up a nasty little problem.
>
> Let's assume you are basing your assumptions for posting your data on
> information in various databases.
>
> What stops you from getting a bad logic check because someone
> else updated a
> record somewhere after you'd gathered that data, but before you commit?
>
> Unless you hold every relevant record open and locked, someone
> could change
> the very data that you're basing your assumption on, thus rendering your
> logic invalid.
>
> Worst case, if it were a total based on something in -every- record over
> several thousand records (let's say a total of something in a detail
> table), you'd run out of file descriptors long before you could lock every
> record.  And unless I'm overlooking something really huge, there's no
> equivalent of LOCK TABLES to rely on.
>
> So how would you prevent something like that--a false-positive test skewed
> by other users during your operations?
>
> One person has told me that it's tacitly impossible, but you've been known
> to achieve the impossible before.  :)  I'm curious if there's a way to
> actually avoid this kind of scenario.
>
> mark->

I think there is a basic understanding among multi-user programmers (you
obvously being included) that there _are_ simply some situations that can
not be "covered". Any report is only as good as the absolutley to-the-minute
data available. If someone changes a record micro/nanoseconds _after_ the
report has been generated... tough. right?  Same has to apply with your
scneario. It can happen, but the overall design is to try and minimize
problems that would be created by such a thing. I try never to hold records
open for longer than the shortest (most atomic limit) that I possibly can...
I am even so anal (in filePro code) as to try and accomplish everything
within one then line... :-) I mean there is no difference between a group of
semicolon'd actions and those actions separated by some blank if lines...
but I still like to cram such important code onto one line if possible...
kind of my little stab at not allowing the kinds of things you are getting
at... which actually could happen, but usually they don't.

John