Passivation problem when jbo.doconnectionpooling=true

Question

Using jdev 10.1.3.4 with jsf/adf bc. We frequently see the row currency error due to the fact that our ps_txn table 'fills up' very quickly. When the rows in ps_txn are deleted manually or via the bc4j sql script the row currency problem goes away. We've scheduled the bc4j sql script to run once daily, when there are no users on the system. However, this doesn't seem to be enough to keep the number of rows in ps_txn to a minimum.
As I understand it after reading the documentation and various threads in this forum, that sql script is really designed to clean out rows in ps_txn that are not cleaned up automatically by the bc4j mechanism due to something like an unexpected app server shutdown and things like that.
According to the documentation - "Under normal circumstances, the ADF state management facility provides automatic cleanup of the passivation snapshot records. When a passivation record is saved to the database on behalf of a session cookie, as described above, this passivation record gets a new, unique snapshot ID. The passivation record with the previous snapshot ID used by that same session cookie is
deleted as part of the same transaction. In this way, assuming no server failures, there will only ever be a single passivation snapshot record per active end-user session."
Our app module is configured using jbo.doconnectionpooling=true. For testing purposes, I've created a two page application. The 'first' page simply has a button which navigates to a second page in which a table of data is displayed via a read only view object. I've found that by simply navigating back and forth between these two pages, a new row is written to the ps_txn each time i navigate between the two pages in the same session. I'm positive that i'm the only user on the system during testing, so I know that these rows that are being added to ps_txn cannot be the result of another user using the system at the same time as me. I've found that after just several minutes of bouncing around in the application as many as a hundred rows can be inserted into the ps_txn table. This is with just one user in the application. Obviously, with multiple users in the application at the same time, the ps_txn table is filling up way too fast as it seems that the 'built in' adf mechanism which is supposed to perform automatic cleanup isn't working properly. Therefore, we frequently encounter the row currency exception because of the number of rows in ps_txn.
I mentioned that our app module is configured with the jbo.doconnectionpooling property set to 'true'. This is because our priority is to keep the number of connections to a minimum. However, for testing purposes, I set that property to false to see the behavior. With that property set to false, bouncing back and forth between the two pages mentioned above doesn't ever result in a row being written to the ps_txn table.
Does anyone have any ideas as to why the ps_txn table is filling up so fast in the above scenario when jbo.doconnectionpooling=true? The automatic cleanup mechanism of the adf framework does not seem to be functioning properly. Thanks for any help on this.
Edited by: user8881206 on May 6, 2010 6:41 AM

Answer 1

I wanted to update this thread with some more findings. I still need help in figuring out why the passivation/activation mechanism is not deleting records from ps_txn in the same user session.
I followed Didier's advice (Passivation table ps_txn not being cleaned up and tested the activation/passivation in the business component browser. This seemed to work fine, as I could see that a row was written/passivated to ps_txn when I selected Save Transaction State and when I selected Restore Transaction State from the menu that row was deleted from ps_txn.
I've also overridden the activateState and passivateState methods in the app module to see if they were invoked as I ran my application:
protected void activateState(Element element) {
System.out.println("activate state called");
super.activateState(element);
protected void passivateState(Document document, Element element) {
System.out.println("passivate state called");
super.passivateState(document, element);
When I run the application, I can see that both these methods are being invoked, but the passivated row(s) are not being deleted from ps_txn for my user session. The passivation continues to write new rows to ps_txn for my session without deleting any of the other rows from the same session. This is resulting in this table filling up way too fast and ultimately causiing the row currency issue. Anyone have any ideas of what's causing multiple rows to be written to ps_txn for the same user session? Thanks for any help.