• Transactions when reading

    From =?UTF-8?Q?Jens_Lidestr=C3=B6m?=@21:1/5 to All on Tue Feb 28 09:43:13 2023
    I'm trying to learn the details of transaction management from here: https://docs.yottadb.com/ProgrammersGuide/langfeat.html#transaction-processing

    This is my question: Is there every any point in using transactions for code that only READS the database?

    That is, enclosing code that only reads from globals in tstart and tcommit.

    If so, when is it appropriate?

    The documentation seems to say that even code that runs without a transaction will only every read the finished result of writes from a transaction. This vaguely suggests that reads don't need transactions.

    I could imagine the following use for transactions for read operations (although I have no idea if this is how it works): To read a snapshot of the database, without seeing ANY updates after the execution of tstart.

    Is this what will happen? Or is there no effect at all?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From K.S. Bhaskar@21:1/5 to All on Tue Feb 28 10:16:52 2023
    On Tuesday, February 28, 2023 at 12:43:16 PM UTC-5, Jens Lideström wrote:
    I'm trying to learn the details of transaction management from here: https://docs.yottadb.com/ProgrammersGuide/langfeat.html#transaction-processing

    This is my question: Is there every any point in using transactions for code that only READS the database?

    That is, enclosing code that only reads from globals in tstart and tcommit.

    If so, when is it appropriate?

    The documentation seems to say that even code that runs without a transaction will only every read the finished result of writes from a transaction. This vaguely suggests that reads don't need transactions.

    I could imagine the following use for transactions for read operations (although I have no idea if this is how it works): To read a snapshot of the database, without seeing ANY updates after the execution of tstart.

    Is this what will happen? Or is there no effect at all?

    Jens –

    If you want Consistency across the reads from the database and the updates that set the values of those globals are not protected by transactions, then yes, it makes sense to put the a set of read-only operations in a transaction.

    Since Isolation is the other side of the coin from Consistency, if you want the reads to be stable, then yes, it makes sense to put the read-only operations in a transaction.

    Regards
    – Bhaskar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Jens_Lidestr=C3=B6m?=@21:1/5 to All on Wed Mar 1 00:00:05 2023
    Thanks, Bhaskar! That's what I expected.

    I take it that the inverse is also true: If I don't need stable values across all reads in an operation, then there is no need for a transaction.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From K.S. Bhaskar@21:1/5 to All on Wed Mar 1 07:16:04 2023
    On Wednesday, March 1, 2023 at 3:00:06 AM UTC-5, Jens Lideström wrote:
    Thanks, Bhaskar! That's what I expected.

    I take it that the inverse is also true: If I don't need stable values across all reads in an operation, then there is no need for a transaction.

    Yes, Jens, that is correct.

    Regards
    – Bhaskar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)