Communicating between to standalones with "write to process" - Found word(s) list error in the Text body

Robert Sneidar slylabs13 at me.com
Sun Dec 8 21:03:47 EST 2013


I get the need for such a thing. In SBT, they needed to update several tables in one transaction, and because Foxpro uses a dBase engine there was no support for this. 

So what they would do is lock the entire tables which required “inserts” and semaphore lock the records that needed “updates”. God forbid someone would crash or the power would go out during one of these transactions! But the time it took, even back then, to accomplish one of these “transactions” was so small that it rarely if ever would occur. We are talking about updating or creating a new invoice. 

If the query involves thousands or more records, I can see how locking down a table for the duration would be impractical. Perhaps that is what staging a transaction is about?

Bob


On Dec 8, 2013, at 11:29 AM, Mike Kerner <MikeKerner at roadrunner.com> wrote:

> Unfortunately, there is not very much written on the topic of multi-stage
> commits.  You will be able to find information on "two-phase commits",
> which is a very basic version of this idea, but TPC involves state
> certainty.  MSC does not.
> 
> Multi-stage commits are sort-of a cross between thinking about data in
> quantum mechanics terms (i.e. the answer to any question depends on whom
> you ask and when, and the likelihood that all answers will be correct, even
> if they are different from each other), and two-phase commits - across many
> nodes.  Yes, there are very important reasons to implement a solution this
> way.  The U. S. Navy, for instance, has, in some cases 25-30 stage commits.
> 
> 
> On Thu, Dec 5, 2013 at 10:41 PM, Robert Sneidar <slylabs13 at me.com> wrote:
> 
>> Multi-stage commits? Wow! I never knew there was such a thing! I’d like to
>> talk about that! I’m going to google that one.
>> 
>> Bob
>> 
>> 
>> On Dec 3, 2013, at 9:47 AM, Mike Kerner <MikeKerner at roadrunner.com> wrote:
>> 
>>> The reason for using the server is that it takes most of the work out for
>>> you, and you just worry about talking to it.  Transactions, triggers,
>>> semaphores, record locking, etc. can all be handled that way.  Now once
>> you
>>> get into multi-stage commits, you and I have to talk because that's a
>> topic
>>> that is generally beyond the scope here.
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> 
> 
> 
> -- 
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list