%ZTER and Transactions...

[Sam Habiel]

While teaching transactions to my Mumps students in Jordan, I had to
revisit and confirm something that caused me a lot of grief when
working on the Scheduling GUI: That %ZTER does not roll back the
transaction; which means that if an error happens inside a
transaction, and gets caught by %ZTER (which naturally stores error
data in a global), and then the transaction subsequently gets rolled
back (By a halt statement or a crash or a TRO), all data stored in the
error global disappears. Doing ^XTER shows that nothing happened,
which is rather misleading.

Of course, you can do your own custom error handler in $ET to do the
rollback before calling ^%ZTER; but custom error handlers are not
exactly easy for beginner programmers to do.

How would we fix this?

Here are my class notes: http://vistapedia.net/index.php?title=Mumps_Class_20

Sam

[David Whitten]

This is an unfortunate occurrence.
I don't think you can mark certain globals as "off limits" to Transaction Processing.
If that existed,  that would be a rather natural way to keep the error logging from being
rolled back.  Maybe we can bring it up on MUMPSter.org as a topic, so we get more
people weighing in on a solution.

David

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

[Sam Habiel]

I posted a link to this topic there. I don't think that mumpster.org
is the right location for the topic, as the name and most of the
content is specifically targeting Mumps, not VISTA; and this is a
purely VISTA problem. Transactions work fine on Mumps without VISTA.

Sam

[Bhaskar, K.S]

I would caution against using transaction processing in VistA - please refer to posts on the topic that I made in the Hardhats list on January 11, 2011.  GT.M's optimistic concurrency control means that to implement ACID transactions, the code cannot store error information in a global - as you noted.  One option with TP is to store the error in a local variable, and then copy it into a global after the TCommit / TRollback.

Regards
-- Bhaskar

-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________

[Sam Habiel]

Bhaskar,

One of the things that ails VISTA is its lack of transaction support.
So in a sense I am agreeing with you; but I don't think I can
recommend VISTA as an EMR to anybody except if it supports
transactions. If you pull the power right now on the server, or more
likely, the process crashes, you leave globals in an inappropriate
state.

Sam

[kdt...@gmail.com]

I thought that after a crash, the entire database did a roll back, as
long as journaling was turned on.

Kevin

On Jun 17, 2:31 pm, Sam Habiel <sam.hab...@gmail.com> wrote:
> Bhaskar,
>
> One of the things that ails VISTA is its lack of transaction support.
> So in a sense I am agreeing with you; but I don't think I can
> recommend VISTA as an EMR to anybody except if it supports
> transactions. If you pull the power right now on the server, or more
> likely, the process crashes, you leave globals in an inappropriate
> state.
>
> Sam
>
>
>
>
>
>
>
> On Fri, Jun 17, 2011 at 4:27 PM, Bhaskar, K.S <ks.bhas...@fisglobal.com> wrote:
> > I would caution against using transaction processing in VistA - please refer
> > to posts on the topic that I made in the Hardhats list on January 11, 2011.
> > GT.M's optimistic concurrency control means that to implement ACID
> > transactions, the code cannot store error information in a global - as you
> > noted.  One option with TP is to store the error in a local variable, and
> > then copy it into a global after the TCommit / TRollback.
>
> > Regards
> > -- Bhaskar
>
> > On 06/17/2011 04:15 PM, Sam Habiel wrote:
>
> > I posted a link to this topic there. I don't think that mumpster.org
> > is the right location for the topic, as the name and most of the
> > content is specifically targeting Mumps, not VISTA; and this is a
> > purely VISTA problem. Transactions work fine on Mumps without VISTA.
>
> > Sam
>

> > On Fri, Jun 17, 2011 at 3:32 PM, David Whitten <whit...@worldvista.org>

> > wrote:
> >> This is an unfortunate occurrence.
> >> I don't think you can mark certain globals as "off limits" to Transaction
> >> Processing.
> >> If that existed,  that would be a rather natural way to keep the error
> >> logging from being
> >> rolled back.  Maybe we can bring it up on MUMPSter.org as a topic, so we
> >> get
> >> more
> >> people weighing in on a solution.
>
> >> David
>

[Sam Habiel]

"the entire database did a roll back, as long as journaling was turned on."

Correct, to the state it was in before; but journaling doesn't address
application data inconsistency. Remember, Globals' state is an
application layer thing. It matters to you if the 10 million is in
your account or somebody else's.

Sam

[Bhaskar, K.S]

Sam --

I agree that transaction processing is worth using - for many reasons.  But it probably has to be brought in incrementally, with due consideration given to each use case.  For example, TP is completely inappropriate in code that interacts with users.  You have shown that with TP, errors cannot be recorded within a transaction.

For what it's worth, I don't think transaction processing is extensively used in many MUMPS applications - our FIS Profile banking application being the notable exception.

Kevin --

Consider a case where an application moves $100 from a checking account to a savings account by subtracting $100 from the checking balance and adding $100 to the savings balance.  If the system crashes right after subtracting the amount from checking but before adding it to savings, you don't want the database restored to that state when the system comes up.  TP ensures that if the system crashes, in the restored database either both the subtraction and addition have happened or neither has happened.  Without TP, even though GT.M may restore the database correctly, the application would still need to a check for accounts out of whack.

I don't know what a medical analog of this example might be.

Regards
-- Bhaskar