4 key distinctions of the new IBProvider v3.4 that make your applications faster
- Possibility to abort lengthy loading of resulting rowsets in SQL scripts.
- Control and adjustment at your own discretion of deferred data loading.
- Background garbage collector became multithreaded.
- Accelerated work with BLOB fields and arrays in updatable rowsets.
1. Now you can abort loading of resulting rowsets in sql scripts
The new IBProvider version has a better implementation of command execution cancellation. Now it is possible to abort not only execution of queries but also loading of resulting rowsets from SQL scripts. This allows to cancel a lengthy loading and continue operation of your application.
2. Now you can control deferred data loading
To optimize performance, the data stored in arrays and BLOB fields is not transferred to the client during execution of the main query. Instead, it is loaded on as-needed basis when the client clearly requests the information.
New IBProvider initialization properties allow to change this behavior. Now you can disable deferred loading of BLOB and arrays for columns and OUT parameters. It is controlled by the appropriate properties deferred_data and deferred_out_param.
Particularities of deferred reading with out parameters and transactions
By default, if OUT parameters are used together with automatic transactions, the data is loaded immediately and deferred loading is disabled. This allows to compete the automatic transaction before exiting the ICommand::Execute method (Command.Execute in case of ADODB).
If a command uses OUT parameters, deferred loading is possible only when BLOB data has been received in the form of an object (Storage Object).
If deferred loading is enabled, the object will load data from the database on request and this will require an active transaction.
If deferred loading is disabled, the BLOB object will be first loaded to the local temporary data storage, and the object will return data from this storage. In this case, an active transaction is not required.
What is temporary data storage?
To store the data used within the framework of one connection, IBProvider can create a temporary pagefile. Initially, the data is loaded to short-term memory cache, which size is defined by the new initialization property temp_stg__memory_usage. If new data is too big for cache, the oldest information is uploaded to the file, and the new information is stored in the memory.
3. Background garbage collector is now multithreaded
In the previous releases, the background garbage collector of updatable rowsets was single-threaded. Now it parallelizes its work. Local temporary data storage also uses background garbage collector.
4. Accelerated work with blob fields and arrays in updatable rowsets.
For the first time ever, deferred and asynchronous operations are used to remove BLOB data from local storages. This allows to reduce actual time a thread spends within IBProvider code.
ensure better performance of your client application that
will continue to perform its main task
while IBProvider is doing all «dirty» work in the background.
Let all «dirty» work be done by IBProvider ver.3.4
all subsequent versions within a year absolutely FREE!