Imagine o usuário da sua aplicação. Ele abre duas janelas que não são modais e em cada uma dá um BEGIN O daemon do PostgreSQL claro abre duas transações, sendo que uma aninhada dentro da outra, pois ele recebeu apenas dois BEGINs. Depois ele recebe um COMMIT. Quem deu COMMIT a primeira janela ou a segunda? Não tem como o banco saber. Ele (claro) vai dar um COMMIT na ultima transação. Mas e se o usuário deu um ALT+TAB e mudou para a primeira janela e deu um COMMIT nela? O usuário pensa que salvou os dados da primeira janela, o PostgreSQL deu um COMMIT apenas na transação aninhada e se o usuário cancelar a primeira transação com um ROLLBACK vai perder tudo.
Se as janelas forem modais o esquema de transações aninhadas funciona, mas se não forem o esquema não funciona. No caso de serem não modais só vai funcionar corretamente se for uma transação por conexão. É só se imaginar no lugar do daemon do PostgreSQL ele tem lá o seu socket de onde saiu 10 BEGINs e depois 1 COMMIT. Me responda agora, de qual BEGIN é o COMMIT? Se as janelas forem modais, da última. Senão de qual foi? Não tem como saber! --- Nelson Pereira Júnior <[EMAIL PROTECTED]> escreveu: > Valeu pelas explicações. > > Mas ainda acho esse método, de ter uma transação > apenas por cliente meio > estranho. Analise comigo. > > Numa aplicação o usuário pode fazer várias coisas ao > mesmo tempo, enquanto > está vendendo um ítem, pode abrir uma outra tela, > simultaneamente para fazer > uma consulta, ou outra para verificar as contas do > cliente, etc... ações que > não devem partilhar da mesma transação, podendo > cancelar essas últimas e > commitar apenas a transação da venda. > > Numa aplicação assim, multitarefa, teria que colocar > uma conexão em cada > tela!!! Isso significa que cada vez que o usuário > quer fazer apenas uma > consulta, deve ser aberta uma nova conexão (que as > vezes pode demorar uns 3 > segundos)... > > Um usuário inesperiente pode abrir umas 10 telas > simultaneamente, (não uma > por cima da outra em modo MODAL que usaria a mesma > transação, mas telas que > deveriam usar transações diferentes, paralelas)... > Isso resultaria que um > mesmo computador cliente estaria com 10 conexões > abertas!!! Você não acha > isso estranho??? > > O que considero ser certo é o modelo que o IBX do > Delphi usa, um Database (a > conexão) e várias transações, quantas eu desejar. > Essa é a maneira ideal > para se implementar um sistema multitarefa, em que o > usuário pode fazer > várias coisas ao mesmo tempo, cancelando umas e > comitando outras. > > Por favor, diga-me o que você acha disso. Se estou > com meu conceito errado, > gostaria de mudar, mas por um conceito que seja > melhor. Queria que você me > ajudasse a entender que o conceito da ZeosLib de > apenas uma conexão é melhor > do que o conceito que o IBX do Delphi usa. > > Obrigado. > > > ----- Original Message ----- > From: "Nabucodonosor Coutinho" > <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, April 17, 2006 10:14 AM > Subject: Re: [PostgreSQL-Brasil] ZeosLib não > controla transações? > > > Nelson Pereira Júnior escreveu: > > >Pessoal, uso a ZeosLib com PG. > > > >No entanto, não estou conseguindo controlar as > transações. > > > >Quando abro uma tela de edição, uma transação > deveria ser iniciada. Quando > >fecho, essa transação deverá ser fechada. > > > >Esse é o meu conceito de transação. > > > > > Bom, sendo bem direto. Seu conceito de transação > está errado. > > >No entanto, o controle transacional do ZeosLib está > no próprio componente > >Connection. Dessa forma, em meu sistema que permite > que várias telas de > >edição sejam abertas simultaneamente, se quisesse > ter um controle de > >transações como mencionado teria que colocar um > Connection para cada tela > >de > >edição. > > > >O que vocês acham dessa forma como a ZeosLib > implementaram o controle > >transacinal? > > > > > Essa é a forma correta de implentar o controle > transacional. Setando a > transação por conexão. Veja por exemplo em java o > início, cancelamento > ou confirmaçao de uma trasação sao métdos do objeto > connection. Nesse > caso deve ser aberta uma conexao para cada transacao > concorrente. A > lógica da implentaçao de transaçao é que um mesmo > cliente (representado > por uma conexao) nao tem necessidade de concorrer > consigo mesmo. > > Isso me leva a crer que voce nao está entendendo o > conceito e a > implentaçao do controle de trasaçoes. > > Imagine que um mesmo cliente provavelmente nao vai > fazer simultaneamente > 1 pedidos de compra e dar baixa no mesmo produto em > n janelas. > > O correto agora para detalhar o processo é o amigo > usar componentes SQL > para entao controlar manualmente as trasações via > SQL com begin, commit > e rollback mas acho que não seja exatamente o caso. > > >_______________________________________________ > >Grupo de Usuários do PostgreSQL no Brasil > >http://www.postgresql.org.br > > > > > > > > _______________________________________________ > Grupo de Usuários do PostgreSQL no Brasil > http://www.postgresql.org.br > > > _______________________________________________ > Grupo de Usuários do PostgreSQL no Brasil > http://www.postgresql.org.br > _______________________________________________________ Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz. http://br.info.mail.yahoo.com/ _______________________________________________ Grupo de Usuários do PostgreSQL no Brasil http://www.postgresql.org.br
