[rt-users] fcgi read timeout error in 4.2.5

[Shawn Plummer]

Doing some more research I see that RT using Oracle used to use File Sesssions and switched in 4.2 to using Oracle. Then a change was made to make sessions default to the MaxAttachment size which, from reading DBD::Oracle documentation, could trigger FOR UPDATE being used causing the locking issue.

I guess the answer for me is to just use Apache Sesssion Files. 

I would be happy to test any solutions for using Oracle for sessions on my devel instance but don’t want to hold up my upgrade any longer. 

The two commits in question
https://github.com/bestpractical/rt/commit/36be526fecd2efb82762bb64978e39381d4a7622
https://github.com/bestpractical/rt/commit/fd66493495acde6a321fd3e560a01002284a198b

I did confirm this bug occurs against a 10g and 11g Oracle database using 4.2

--
Shawn Plummer
Systems Manager | SUNY Geneseo
South Hall 119 | 585-245-5577 | http://www.geneseo.edu/cit

On Jul 29, 2014, at 10:49 AM, Shawn Plummer <plummer at geneseo.edu> wrote:

> I have done some more digging and am unable to determine the code causing the FOR UPDATE to be issued.
> 
> Does anyone have rt 4.2.x running against Oracle successfully?
> 
> --
> Shawn Plummer
> Systems Manager | SUNY Geneseo
> South Hall 119 | 585-245-5577 | http://www.geneseo.edu/cit
> 
> On Jun 24, 2014, at 4:24 PM, Alex Vandiver <alexmv at bestpractical.com> wrote:
> 
>> On 06/24/2014 04:03 PM, Shawn Plummer wrote:
>>> [snip]
>> 
>> Please keep replies on-list.
>> - Alex
>> 
>>>> Sounds like it's indeed related to session locking.  You can try
>>>> switching to on-disk sessions and see if it resolves the issue:
>>>> 
>>>>   Set($WebSessionClass, "Apache::Session::File”);
>>>> 
>>> Running this way did indeed prevent the error from occurring. We
>>> switched back to database sessions to perform more testing.
>>> 
>>>> However, we'd also be interested to hear what your DBA discovers about
>>>> the deadlocks, as this issue may well bite other Oracle users, and we'd
>>>> like to resolve it.
>>> 
>>> Our DBA has been doing some research and believes FOR UPDATE in this
>>> statement is the issue
>>> 
>>> SELECT a_session
>>> FROM sessions
>>> WHERE id = :p1 FOR UPDATE
>>> 
>>> From Oracle Doc:
>>> How Oracle Database Locks Data
>>> 
>>> Locks are mechanisms that prevent destructive interaction between
>>> transactions accessing the same resource—either user objects such as
>>> tables and rows or system objects not visible to users, such as shared
>>> data structures in memory and data dictionary rows.
>>> 
>>> In all cases, Oracle Database automatically obtains necessary locks when
>>> executing SQL statements, so users need not be concerned with such
>>> details. Oracle Database automatically uses the lowest applicable level
>>> of restrictiveness to provide the highest degree of data concurrency yet
>>> also provide fail-safe data integrity. Oracle Database also allows the
>>> user to lock data manually.
>>> 
>>> More
>>> details: http://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm#CNCPT020
>>> 
>>> There is also a doc showing that SELECT FOR UPDATE behavior is different
>>> from 10g to 11g. Doc ID 858518.1
>>> 
>>> And further information on FOR
>>> UPDATE http://markjbobak.wordpress.com/2010/04/06/unintended-consequences/
>>> 
>>> 
>>> --
>>> Shawn Plummer
>>> Systems Manager | SUNY Geneseo
>>> South Hall 119 | 585-245-5577 | http://www.geneseo.edu/cit
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20140729/fc7812e9/attachment.htm>