The architecture and connection differences lead to the following transaction differences between PowerBuilder and PowerServer.
One transaction vs. multiple transactions
In PowerBuilder traditional C/S applications, for each transaction object, the same transaction is used through the entire lifespan of the application. The transaction is opened when CONNECT statement is executed (and then it is kept open) and closed when the DISCONNECT statement is executed. The long-running connection and the C/S architecture make this possible.
In installable cloud apps, a transaction will start when a connection is borrowed from the pool, and the transaction will close when the connection is returned to the pool. Therefore, for each transaction object, multiple transactions may be opened and closed (in sequence) through the entire lifespan of the application. The opening and closing of transactions is managed implicitly, or explicitly when Commit/Rollback is executed in the code or AutoCommit = true.
For example, in PowerServer, when AutoCommit = false:
-
When querying the database (such as running DataWindow Retrieve or embedded SQL Select), PowerServer automatically starts and then closes the transaction (implicit management).
-
When updating the database (such as running DataWindow Update or embedded SQL Update/Delete), PowerServer starts a transaction automatically and then close it when a Commit/Rollback is explicitly executed in the code or the transaction timeout is reached.
Transaction timeout vs. no transaction timeout
In installable cloud apps, network connection problems can cause commands to fail, and if the transaction timeout value is not set properly, it can lead to deadlocks of concurrent calls. Therefore, it is very important to have transaction timeout in PowerServer and set a proper value for it. However, there is no such concept as transaction timeout in PowerBuilder traditional C/S applications because there is no network connection issues in C/S architecture.
Such difference would cause problems in PowerServer: during the execution of a stored procedure, if the transaction is not closed (when Commit/Rollback is not executed in the code or AutoCommit = false), then when the transaction timed out in PowerServer, a "Transaction is timeout" or "Transaction does not exist" error occurs. To resolve this error, use the ProcedureInTransaction parameter of Transaction.DBParm. Read more.
PowerBuilder C/S app has no such error because it is always the same one transaction and the transaction never times out in PowerBuilder C/S app.