The error you are seeing is a DB Oracle error and occurs if you have a session that has locked a record and your session is trying to modify the same record. Locking a record is usally done before modifying a record and is usually resolved instantly. 

When you say custom process you mean a customized WaDaCo process or just a custom configuration? If it’s the former you likely have some bad programming where either a record is locked and no udpate performed or no rollback is performed after an error on update. 

Since the system is getting slow before it happens it’s also possible that the actions you perform include some actions in a loop with bad performance. If too many tasks try to access the same Funtion simultaniously or are even creating autmatic tasks too frequently i have had the same thing happen (e.g. background job from third party system running an update function on 100K objects via single DB calls every 30 secs. It created some 100 simultaneous sessions within a few hours blocking each other).

Other options are background jobs, some developer using pl/Sql developer on PROD and modifiying data w/o commit etc. 

When the error occurs again have a look at the open Sessions in the DB: Select * from V$Session where Status = ‘Active’ and look for long running ones, most likely calling a function in one of the WaDaCo sessions (Don’t quite remember, but should be something with Data_Capture_Session or similar). 

You can also check on the column Blocking_session if you find any with a value. That session is then likely the cause for locking the object. 

The error likely resolves itself because Oracle is rolling back uncommited tarnsactions after a while if the session is idle. 

Good Luck :-)

It’s a modified WaDaCo transaction.  Not a custom configuration.  

Thanks for the advice. 

You might also try this to see if there is a session with open transactions:

SELECT *

FROm v$transaction t,v$session s,v$mystat m

WHERE t.ses_addr=s.saddr

AND s.sid=m.sid
 

That way you can manually end the session and hopefully also get more info on what DB call is causing the  issue. 

Hi @cjones_saab 

You didn’t mention which version of the scan it app you are using, for android on apps10 we have both the app based on the old mobile fw ‘IFS Apps 10 Scan it’ and we have the new one based on the aurena mobile fw ‘IFS Aurena Scan It 10’.

In your case I would guess that you might be using the aurena app (IFS Aurena Scan It 10), since the issue you mention seems to be something that was noticed a lot 1-2 years back with that app.

The problems around was the list in the scanit app had performance issues especially when the session tables where extremely large (like millions of session lines). Also later on after we fixed that issue in the app (a year ago) another issue popup where list got slower and slower and seem to crash the app after a while (like a memory leak). I think that one was fixed this year maybe, I think @Rukmal Fernando  or @JOOLSE might have some insight in which update the mobile fw list issue got fixed in?

So you probably need to upgrade to get those issues sorted.

There is 2 workarounds, if you can’t upgrade soon:

• Use the other app (IFS Apps 10 Scan it) instead since it didn’t have those issues (downside is that it requires account manager to login with).

• Change the configuration and try and hide as much info as possible in the list so the list is not built up to much.

Also check that the wadaco cleanup background job (Remove Data Capture Sessions) is run regularly to avoid having the session tables getting to large.

Dario - What are the session table names you are referring to?   We’d like to check row counts to see if this looks like our issue. 

Thanks

@cjones_saab 

It is mainly these 2 tables:  DATA_CAPTURE_SESSION_LINE_TAB and DATA_CAPTURE_SESSION_TAB, but for the app performance thing I think it was mainly DATA_CAPTURE_SESSION_LINE_TAB that could affect the performance in the list. 

Hi Chris, Sebastian here :)

I don’t remember if we scheduled the background job that clean up old sessions, so please check that as Dario already mentioned: It’s two jobs that you should schedule (Remove is the most important one): 

• Park All Active Data Collection Sessions
• Remove Data Capture Sessions

You could run these two jobs on Sundays for example when no one is working. First you run the “Park” Job and then the “Remove” job. Note that you control on each configuration for how many days you want to save sessions before they are removed. 

Also note that we disabled the “auto-update” of the WADACO Scan It client on the devices. That means that you are running an old version of the client. I would recommend that you try to update that and see if that helps as well. Using the other client that Dario refers to I guess is not an option since that client doesn’t provide any “login/logout” functionality and as far as I remember they share devices and needs that capability. 

Best regards Sebastian

Hi Sebastian !!  So good to hear from you.   We are aware of these jobs and they are currently running.  We did reduce the number of days we were retaining for the problematic flows to see if this would help.   

We discussed updating the client app last week as well but are waiting to see if we find any other issues.  ​​​​​​

Thanks for the good advice.