[RT-es] Consulta Get Lock RT DB

[Carlos Fuentes Bermejo]

Hola Sebastian,
El 10/01/2009, a las 22:49, Sebastian Parada escribió:

> Hola Carlos,
>
> Carlos Fuentes Bermejo escribió:
>> Hola Sebastian,
>>
>> El 07/01/2009, a las 14:30, Sebastian Parada escribió:
>>
>>>
>>> Estimados,
>>>
>>>
>>> Junto con saludarlos , quería exponerles el siguiente problema que  
>>> se me
>>> esta presentando en mi RT.
>>>
>>> El tema es el siguiente desde un tiempo a esta parte , hemos  
>>> notado que
>>> varias veces en el día  RT, queda bloqueado impidiendo que los  
>>> usuarios
>>> puedan trabajar con la aplicación , buscando en el log , me di  
>>> cuenta
>>> que esto se produce por un bloqueo en base de datos.
>>>
>>> Datos:
>>> ____________________________________________________________________________
>>>
>>> PDATE Tickets SET EffectiveId='17354' WHERE id='17354'
>>> UPDATE Tickets SET LastUpdatedBy='1' WHERE id='17354'
>>>
>>> En los logs se registra lo siguiente,
>>> 1463226 usr_rt  server.cl:36939   rtdb    Query   176     User
>>> lock       SELECT
>>> GET_LOCK('Apache-Session-f7384d19018c74854adbab5cd48c5935', 3600)
>>> ____________________________________________________________________________
>>>
>>>
>>>
>>> Resulta  que he encontrado varias alternativas de solución pero la  
>>> verdad no se cual es la mejor ,
>>>
>>> 1) cambiar la prioridad en la base de datos , de los update versus  
>>> los select (no me parece una muy buena solución)
>>>
>>> 2) Modificar en rt el archivo MySQL.pm , y modificar el GET_LOCK  
>>> de 3600 a 1 (No se si esto sea optimo)
>>>
>>> 3) y por ultimo cambiar el manejo de sesiones de apache , es decir  
>>> descomentar la linea
>>>
>>> # Set($WebSessionClass , 'Apache::Session::File');   ' para  
>>> permitir que las sesiones se manejen en archivo y no en la BD.
>>>
>>> Apelando a su experiencia no se si les a ocurrido algo parecido ,  
>>> si me peuden orientar de antemano muchas gracias.
>>
>> La verdad es que a nosotros tambien nos ocurre lo mismo,  la  
>> solución que habiamos que usamos ahora mismo, un poco cutre, es  
>> reiniciar el navegador, con lo que solventamos el problema, ya que  
>> el usuario crea una sesion diferente que no esta bloqueada. Despues  
>> de tu mensaje, buscando un poco, vi un problema parecido al que  
>> describes, y al que Jesse da la siguiente solucion:
>>
>> The lock will also automatically time out in 5 minutes, or whenever  
>> the
>> page you didn't finish loading times out.  One possible fix
>> is to switch to using Apache::Session in non-locking mode. In _very_
>> rare cases, it could lead to a missing uploaded attachment.
>>
>> Espero que esto te ayude.
>>
>> Salu2,
>> Carlos
>> -- 
>> Carlos Fuentes Bermejo <carlos.fuentes en rediris.es>
>> Security Specialist - IRIS-CERT
>> RedIRIS/Red.es
>> Tel: 91 212 76 20/25 Ext: 5583
>> www.rediris.es - http://www.rediris.es/cert
>> PGP key: http://www.rediris.es/keyserver
>>
>>
> Esto quiere decir, que debo cambiar el manejo de sesiones en  la  
> base de datos a non-locking mode??? o debo configurar  
> Apache::Sessions, en non-locking Mode??

Siento no haber sido claro, el Apache::Sessions debe estar en non- 
locking mode.

Carlos

--
Carlos Fuentes Bermejo <carlos.fuentes en rediris.es>
Security Specialist - IRIS-CERT
RedIRIS/Red.es
Tel: 91 212 76 20/25 Ext: 5583
www.rediris.es - http://www.rediris.es/cert
PGP key: http://www.rediris.es/keyserver


------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : PGP.sig
Tipo       : application/pgp-signature
Tamaño     : 194 bytes
Descripción: Mensaje firmado digitalmente
Url        : http://lists.bestpractical.com/pipermail/rt-es/attachments/20090111/a445f461/attachment.pgp