I was performing experiments based on sample application from my last post - RowLockingApp.zip. You can download it as well, and try to play by adjusting AM settings and checking generated results.
There are at least two AM tuning settings we should keep in mind, when AM implements immediate row level locking:
- AM pool size
- AM time to live
By default, maximum pool size and referenced pool size are set to 4096 and 10 respectively:
We can simulate stress test environment, by setting both values to 1. This means, there will be enough space only for one single AM instance at one time. If there will be two sessions active, one of them always will be passivated. Stress environment simulation AM pool size settings:
We open two web sessions, one is session A:
Second is session B:
Session A obtains row level lock:
AM pool size allows to maintain only one AM instance (as defined for stress test simulation). When session B performs submit and wants to lock the record, because there is no free space in the pool, AM instance from session A will be passivated. AM instance from session B will steal session A spot from AM pool - session A passivation/session B activation will happen:
During session A passivation, session A obtained lock will be removed and session B will get this lock:
This means - for these AM's, where immediate row locking is implemented, you need to make sure AM pool size is sufficient to serve all concurrent users. Otherwise, if AM instance of that session which owns the lock will be passivated, this session will loose that lock even before commit/rollback or logout actions - as it happened based on example above.
Another important property - AM time to live (more about this setting - Optimizing Oracle ADF Application Pool). Make sure this value is always greater than web session timeout. For test purposes lets set web session timeout to 15 minutes:
AM time to live will be set to 2 minutes, which is less than 15 minutes for web session timeout:
Let's see what happens - session A opens and locks the record:
Session B starts, user prepares to lock for editing the same record as session A currently locks:
If this happens during the first 2 minutes of session A inactivity, when AM instance of session A is still not destroyed - session A will keep its lock and session B will not be able to edit (as expected):
However, after AM time to live period is expired - AM instance for session A will be destroyed and session data will be passivated, this means lock will be removed:
Even A web session is still active, lock will be lost - session B will be able to obtain it and prevent session A commit/rollback or logout actions:
In order to prevent lock removal, make sure you keep AM time to live longer than web session timeout.
We open two web sessions, one is session A:
Second is session B:
Session A obtains row level lock:
AM pool size allows to maintain only one AM instance (as defined for stress test simulation). When session B performs submit and wants to lock the record, because there is no free space in the pool, AM instance from session A will be passivated. AM instance from session B will steal session A spot from AM pool - session A passivation/session B activation will happen:
During session A passivation, session A obtained lock will be removed and session B will get this lock:
This means - for these AM's, where immediate row locking is implemented, you need to make sure AM pool size is sufficient to serve all concurrent users. Otherwise, if AM instance of that session which owns the lock will be passivated, this session will loose that lock even before commit/rollback or logout actions - as it happened based on example above.
Another important property - AM time to live (more about this setting - Optimizing Oracle ADF Application Pool). Make sure this value is always greater than web session timeout. For test purposes lets set web session timeout to 15 minutes:
AM time to live will be set to 2 minutes, which is less than 15 minutes for web session timeout:
Let's see what happens - session A opens and locks the record:
Session B starts, user prepares to lock for editing the same record as session A currently locks:
If this happens during the first 2 minutes of session A inactivity, when AM instance of session A is still not destroyed - session A will keep its lock and session B will not be able to edit (as expected):
However, after AM time to live period is expired - AM instance for session A will be destroyed and session data will be passivated, this means lock will be removed:
Even A web session is still active, lock will be lost - session B will be able to obtain it and prevent session A commit/rollback or logout actions:
In order to prevent lock removal, make sure you keep AM time to live longer than web session timeout.
Hi Andrejus,
ReplyDeleteThanks for the useful article, I also read Optimizing Oracle ADF Application Pool.
I have an issue with Application Module (AM) session, I have at least four AM, 'orders' is the most important.
In my adf application it is neccesary high availability for long periods of time, like three hours, few users.
It was developed a 'heart beat' implementation, in order to prevent that application session be destroyed, it works.
In web.xml, session timeout is 30 minutes, but 'heart beat' prevent a logout.
The problem is:
Like a Viewer profile, like me, I am monitoring if everything is ok, I can have my application session forever opened and jump between JSPXs without problems (I go to lunch, when I come back the screen is the same, then I invoke a refresh button, and it works).
but Operators use the principal AM a lot, and they have problems related with the AM, it seems that our AM, in some point, doesn't care about 'heart beat', and invokes logout, no matter if there is a proccess pending to be done, like an execution of an stored procedure.
We don't have problems with datasource pool. AM pool size, AM time to live, have the defaults: maximum pool size and referenced pool size are set to 4096 and 10. jbo.ampool.timetolive:3600000. The problem is not a profile issue, if I'd use the AM it wouldn't work neither.
Please advice me..
Thanks,
Myriam
Hi,
ReplyDeleteMay be AM instance time to live should be increased, to be larger than heart beat period.
Andrejus