Developing for the Web (Magic xpa 4.x)
As mentioned in earlier sections, in order to have concurrency, the lock and the transaction need to be as short as possible. A Web application can serve thousands of users at the same time all over the globe, and locking a resource can make the application unavailable to some users. The client in this kind of an environment is disconnected from the server and, as a result, from the database server. When the user will actually commit the transaction is unknown. The user may also exit the browser by unconventional means, such as clicking the browser’s Close button or by moving to a different Web page. In this case, the transaction would be kept open until the Magic xpa context times out.
As a result, the recommended transaction mode of a Browser task is a deferred transaction.
You should carefully consider when the transaction should be opened. There are no hard and fast rules, but we will try and provide some basic guidelines:
Browser tasks that are opened from a menu task are usually expected to open an independent transaction, which is why the Transaction mode property of the menu task should be set to None.
Set the Transaction begin task property to Before Record Prefix if you want to have every record committed immediately when the record is exited or, alternatively, to roll back each record modification separately.
|
|
Take into consideration that in a record level transaction, the browser client connects to the remote server for every record that is modified.
|
Set the Transaction begin task property to Before Task Prefix if you wish to have all the modified records committed only when the task is closed or, alternatively, to roll back all the modifications of the task records as a single unit.
|
|
Setting the transaction as task level will reduce the number of times that the browser client will contact the server.
|
