If your Sessions table has grown very large, you might want to investigate using a cron job to regularly clean up sessions.
Ok,
Sessions table was tiny, but we cleaned it up anyway.
From my DBA:
An inactive session has a blocking lock on an active session. Looks like the lock is on the sessions table.
The RT app is just expecting it’s statements to be committing without it doing so itself. The first connection does an update, taking out a lock, but then just sits there. The next connection tries to do an update but can’t because of the lock.
Is there any doco for RT that autocommit needs to be on?
I couldn’t find anything relating to RT and autocommit, anyone have more advice?
Just wanted to now add, that we’ve tried a completely “from scratch” install, new database, creating the user and all the pems/data-load using the init script… empty install from 5.0.0 (no upgrades)…
And it still suffers the same issues, table stuck in a lock after the first load… still pointing to a lack of autocommit.
Could this be an issue due to using oracle instant client and not the full oracle client?
You could test this by trying to change the session from using the DB to using a file based session store:
If that works then it points to the locking on the db table as a potential culprit.
Yeah def could be a legit bug
1 Like
I’ll submit it then.
Pretty frustrating to find out what was actually going on.
I’ve really appreciated your help during this one, once you get to that point of being totally out of ideas, having someone else to throw them at you is a huge help (mentally).
Alright, consider this one closed.
I don’t think it’s a RT5 bug. We have the same problem with RT 4.3.3. (after migrating from MariaDB 10.1 to Oracle 19). It is exactly the same problem that was already reported as a bug in 2014 in bug report 274520.
Oracle seems to have problems with the RT call SELECT FOR UPDATE. Is there anyone here who runs RT with Oracle and can report something about this?