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
