[rt-users] fcgi read timeout error in 4.2.5

[Alex Vandiver]

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
>