Oi Rodrigo,

O ZODB não trabalha com o modelo de tratamento de colisões de transações através de bloqueios. Esse modelo é pessimista e prejudicaria muito a performance de uma vasta gama de aplicações web.

Aplicações web são um pouco diferentes de aplicações relacionais em geral, pois a relação leituras (acessos ao site) e gravações (modificações de informações) costuma pesar muito mais para as leituras. Dessa forma, usar bloqueios iria contra a lógica. O que o ZODB usa é um sistema de tratamento de colisões baseado em timestamps (otimista). Ele parte do presuposto que em 99,99% do tempo não há transações colidindo e isso é muito bom. As versões do ZODB mais recentes ainda implementam uma abordagem MVC (multi-version) que minimiza ainda mais a os problemas.

O que você deve providenciar é uma forma de sua aplicação não dar esses conflict erros. Se voce tem um script qualquer que leva 2 minutos para rodar e altera objetos e, durante esse tempo, há pessoas acessando o mesmo dado que está sendo alterado, você está pendindo para tomar pancada.

Eis algumas formas de mitigar os problemas:

1) Usar um ZODB MVC que vem o Zope 2.8. Isso não resolve o problema, mas ajuda bastante.

2) Otimizar ao maximo o processamento da transação que altera dados. Se isso não for possível, pense em fazer isso num horário onde há menos gente acessando (madrugada?). Se voce tem que fazer isso a cada 5 minutos, bem... ai comeca a ficar dificil, mas mesmo assim há soluções.

3) Um solução seria usar subtransacoes. O ZODB permite que, a medida que voce for fazendo sua transacao, que voce de commit parciais. Isso significa que, se depois de 1 minuto de processamento houver um conflito, voce nao precisa dar rollback de toda transacao. Obviamente isso influencia na forma como voce deve enxergar o funcionamento de seu programa, mas transacoes de longa duração são chatas mesmo.

Por fim, tenha ciencia que, mesmo usando um esquema de bloqueios estritos (como o que Oracle usa, por exemplo) seu problema ainda aconteceria. Ter uma transacao que dura minutos com muita gente lendo dados SEMPRE impactara negativamente na performance de qualquer banco de dados. Em alguns esse impacto é menor do que outros, mas não existe solução perfeita (alias existe...desenvolver aplicações/plataformas que se preocupem com isso e prevejam isso nos seus projetos).

Espero ter ajudado.

Xiru

On 5/19/06, Rodrigo Braga <[EMAIL PROTECTED]> wrote:
o erro está ocorrendo no momento que o Zope tenta gravar no ZODB uma variável sessão, talvez o "time out" não resolva, não sei ... e no nosso caso aqui, não tem como otimizar a chamada SOAP.

parece que o ideal era o ZODB ter essa "feature" ... acredito eu :)

Fugindo um pouco do problema, mas ainda sobre o ZODB; de qualquer forma (mesmo com sistemas bem modelados e talz) não seria interessante ter esse controle mais rígido e etc. ("lockar" o objeto e etc.)?!

Ou pelo menos deixar essa opção pro usuário (no zope.conf por exemplo) para ele escolher essa alternativa caso queira (ainda que a queda de desempenho ocorra)?

xiru < [EMAIL PROTECTED]> escreveu:
Na pratica, nenhum sistema bem modelado pode ter uma thread no zope "presa" durante muito tempo. O que voce deve fazer é delimitar as suas chamadas para durarem um tempo maximo (timeout por chamada) para evitar esse tipo de problema (ou se esforcar para o servidor webservices responder mais rapido, o que nunca é garantido).

O SOAPpy nao implementa timeout por padrao, mas se voce quiser que ele faca isso, procura por um patch que eu mandei para a lista da pywebsvcs a uns meses atras que voce acha.

On 5/19/06, Rodrigo Braga <[EMAIL PROTECTED] > wrote:
Pessoal

Estamos aqui com um problema delicado e que ao que tudo indica não há cura por hora.

A situação é a seguinte:

a thread A é disparada ... ela espera uma resposta (SOAP) que pode demorar muito (mais de um minuto até), e nesse meio-tempo a thread B é lançada ... ela tenta gravar no mesmo objeto que a A, como o ZODB não deu lock ... a exceção conflict erro é levanta!

Um problema crônico, essa operação faz N coisas, inclusive gravar dados em um SGDB, e ao dar o conflict error a thread B é lançada denovo, duplicando algumas coisas!

Bem, claro, é muito mais "sinistro" que isso, essa é uma visão geral do drama vivido aqui, então pergunto, como contornar isso?!

Segundo nossas pesquisas parace que esse controle (lock, unlock) foi abortado por questões de desempenho e talz; porém em situações como essa ele está fazendo falta!

http://www.tchezope.org/documentacao/publicacoes/zodb/document_view

No link acima na seção "controle de concorrência" relata o que está havendo aqui.

Qualquer opnião/ajuda é bem vinda! :-D

PS.: Espero que nehum engraçadinho recomende usar Java com Struts, Hibernate e cia. -- pra descontrair apenas, senão ninguém aguenta -- para resolver isso :D


Yahoo! Search
Música para ver e ouvir: You're Beautiful, do James Blunt

Para enviar uma mensagem: zope-pt@yahoogrupos.com.br
Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED]



Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE


Links do Yahoo! Grupos



--
Fabiano Weimar dos Santos
Plone Developer and Consultant


Abra sua conta no Yahoo! Mail - 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz.


Para enviar uma mensagem: zope-pt@yahoogrupos.com.br
Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED]



Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE


Links do Yahoo! Grupos




--
Fabiano Weimar dos Santos
Plone Developer and Consultant

Para enviar uma mensagem: zope-pt@yahoogrupos.com.br
Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED]



Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE


Links do Yahoo! Grupos

Responder a