Transaction differences
The architecture and connection differences will 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.