I'm confused. Doesn't a successful commit prevent a future rollback? Why isn't the scenario:
A: commit succedes B: commit fails B: rollback succedes B: rerunning transaction succedes B: commit succedes -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Colin Paice <0000059d4daca697-dmarc-requ...@listserv.ua.edu> Sent: Monday, February 19, 2024 10:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nanosecond resolution timestamps for HLL's? no... it is standard transactional practice. This is what happens to DB2/MQ etc. Bear in mind A or B (or both) could have decided to roll back any updates. On Mon, 19 Feb 2024 at 15:32, Seymour J Metz <sme...@gmu.edu> wrote: > In that scenario, doesn't the second commit fail? > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Colin Paice <0000059d4daca697-dmarc-requ...@listserv.ua.edu> > Sent: Monday, February 19, 2024 10:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Nanosecond resolution timestamps for HLL's? > > Another example of these timing type problems are having two instances(A > and B) doing a database insert. > > - Instance A inserts data record a - not visible because commit not yet > done > - Instance B inserts data record b - not visible because commit not yet > done. > - B gets dispatched and issues a commit > - A gets dispatched and issues a commit. > > What we see in the database over 3 clock ticks is > > - no records > - record b > - records a and b > > for the duration it takes A to commit, only record b is present. > Once A has committed you will see record a and record b. > > As Peter said you need some synchronisation between tasks, or have just one > task doing the work. > > Colin > > On Mon, 19 Feb 2024 at 15:03, Peter Relson <rel...@us.ibm.com> wrote: > > > It might be said that the notion of monotonicity with respect to clock > > values is not "valid" unless you are a single-threaded application or all > > your references are serialized across all the threads (such as by a step- > > or system- or systems-level ENQ depending on the characteristics). > > > > Otherwise you cannot possibly tell what is what because thread one might > > have captured clock value "n" and then gotten interrupted, and then > thread > > two captured clock value "n+1" and then continued to completion, after > > which thread one was re-dispatched (with what is now an older time stamp > > than the one already captured). > > > > If these two threads were serialized by an ENQ against each other the > > above scenario would not happen because thread two would not have been > able > > to get to the point of capturing its clock value. > > > > Peter Relson > > z/OS Core Technology Design > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
