Progress-4gl: in che modo l'ambito della transazione si applica alle chiamate di programmi esterni?

Aug 20 2020

Ho bisogno di aiuto per comprendere l'ambito delle transazioni per procedure/programmi al di fuori del programma corrente.

Supponiamo di avere tre programmi, programma A, programma B e programma C. All'interno del programma A, ho una procedura che contiene alcune righe racchiuse in un do transactionblocco (non fortemente tipizzato). All'interno di quel do transactionblocco, chiama un altro programma B. Al ritorno dal programma B c'è un comando undo, leave. All'interno dello stesso blocco di transazione, chiama il programma C e ha un annullamento, lascia anche dopo questa chiamata.

La mia domanda è, se all'interno del blocco della transazione, il programma B viene eseguito senza errori, ma il programma c ha restituito un errore, l'annullamento, la partenza dopo la chiamata al programma C annullerà anche le transazioni avvenute all'interno del programma B?

Procedure do_something:
  some processing....
  do transaction:
    error-message = "".
    {run programB.p}
    if error-message <> "" then undo, leave.
  
    some further processing...
  
    error-message = "".
    {run programC.p}
    if error-message <> "" then undo, leave.
  end. /* end of do transaction */
end procedure.

Risposte

4 MikeFechner Aug 20 2020 at 02:58

Sì. Tutto ciò che accade nel blocco della transazione verrà annullato.

5 TomBascom Aug 20 2020 at 04:01

Sì. Nell'esempio che descrivi, tutto viene ripristinato.

Non è tanto che è "esteso" di per sé, ma solo che la transazione include tutto ciò che accade in quella sessione dal momento in cui è abilitata fino a quando non viene eseguita o ripristinata. Procedure interne, procedure esterne, funzioni definite dall'utente, metodi di classi, codice trigger ecc.

"In quella sessione" è importante: se chiami una procedura su un server app tale attività NON è inclusa poiché è il proprio processo con il proprio contesto di transazione distinto.

Quando sono coinvolti i server delle app, le cose si complicano. Il chiamante originale non ha alcuna capacità (incorporata) di sapere cosa eseguire il rollback nella sessione del server app chiamata. La chiamata al server dell'app potrebbe restituire un errore che causa il rollback del chiamante in caso di problemi, ma il chiamante potrebbe anche decidere di intercettare e ignorare l'errore.