ADF BC Reserved Mode for DB Connection Critical Applications

With this post I would like to explain how you can control ADF BC mode and switch from default managed to reserved mode and back. With default managed mode, there is no guarantee in ADF BC for DB connection to stay assigned for the user session. Why it is highly recommended to design your ADF application in such way to be compatible with default managed mode, there are exceptional scenarios when we want to guarantee DB connection to stay the same between requests. Reserved mode allows to guarantee DB connection and there is a way to switch between modes on runtime. You can read more in ADF developer guide - 40.4 Setting the Application Module Release Level at Runtime.

Sample application - ReservedModeADFApp.zip, is developed to demonstrate how you can switch between managed and reserved modes. You can change any field and click Prepare Data, this will post it to DB. By default, data will be lost during the next request. However, if you click Enable Reserved Mode - ADF BC will switch to reserved mode and DB connection will stay assigned, until you will switch back to managed mode again:

Prepare Data button calls ADF BC post operation, to post data to DB. There are two key methods here - enableReservedMode and disableReservedMode. As you can see, it is pretty straightforward to switch between modes, you only need to call setReleaseLevel method available as part of ADF BC API:

Application Module configuration is set with all default settings, also DB pooling is enabled:

We should test how it works to switch between two different modes - managed and reserved. Let's change data in any field, for example Hire Date:

Click Prepare Data button to post changes for Hire Date to DB:

Click Save button to commit transaction:

At last, click Cancel button to check if previously posted changes were committed to DB:

You can see - changes in Hire Date are reverted back, as change was not saved after it was posted. Application Module is set with DB pooling, means during each request it will return DB connection back to the pool and get another one on the next request. This would mean all changes posted to DB are lost:

This is correct behaviour. But in some exception cases, we would like to keep DB connection between requests. We could force this by switching Application Module into reserved mode. By default, when DB pooling is enabled, you can see there are zero DB connections used (connections are returned quickly to the pool after request completion):

We should repeat our test, but little different now. Before posting changes to DB, click Enable Reserved Mode button - this will switch Application Module to reserved mode and guarantee DB connection across requests:

You can see from the DB connection monitoring, one connection gets reserved now and stays assigned:

Click button Prepare Data now, to post changes to DB when reserved mode is on:

Click Save button to commit transaction:

Click Cancel button to see if recent changes will be reverted:

Changes are not lost this time, means posted data was successfully committed in the next request, when Save button was pressed:

Changes were posted and committed to DB, we can switch back to default managed mode. Click Disable Reserved Mode button:

You should see from DB connection monitoring graph, previously reserved DB connection should be returned back to the pool: