[rt-users] fcgi read timeout error in 4.2.5

[Shawn Plummer]

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/ace57b67/attachment.htm>