Select Lock
In REST APIs, each request must contain all of the information
necessary to understand the request, and cannot take advantage of any
stored context on the server. This is known as the stateless
constraint of REST. Stateless does not mean there is no state; but the
state is maintained on the client side instead of the server
side.
However, in PowerBuilder, the transactional information must be
maintained on the server side in order to provide context for
subsequent transactions.
Due to this difference, the REST APIs in PowerServer have been
adjusted to support the PowerBuilder transactions. When the REST APIs
handle requests for Update, Insert, and Delete, a transaction will be
started automatically, the transactional information will be stored on
the server, and a default transaction timeout value is set. This will
cause some differences to the Select Lock scripts. For example,
Original PowerScript:
|
1 2 3 4 5 6 |
//DOES NOT hold the lock Select max(1) Into :ll_test From table b with(updlock, ROWLOCK) Using sqlca; //in this case there is no open transaction and no locks. If you run in regular pb, there are locks. |
Must be modified like below to work in PowerServer:
The “trick” is to hold the transaction open:
|
1 2 3 4 5 6 |
Update table A Set col1 = Set col1 where col1 = 1 USING SQLCA; //lock held Select max(1) Into :ll_test From table b with(updlock, ROWLOCK) Using sqlca; //now if you check the locks in sql server, you will see that they exist on table b (as well as table a) |