Controle de Concorrncia com Java e e Bancos de Dados Relacionais

Srgio Soares Paulo Borba e Centro de Informtica a Universidade Federal de Pernambuco

Abstract The advent of information systems based on the World Wide Web increased the impact of concurrent programs in society. Such increase demands the denition of guidelines for obtaining safe and ecient implementations of concurrent programs, since the complexity of implementation and tests in concurrent environments is bigger than in sequential environments. This paper denes guidelines for concurrency control in object-oriented systems written in Java and using relational databases. In particular, we show how and where the programming language and the relational database features can be used for concurrency control. The main point of the guidelines is to guarantee system correctness without redundant concurrency control, both increasing performance and guaranteeing safety.

Resumo O advento de sistemas de informaao baseados na World Wide Web aumentou o impacto c dos sistemas concorrentes na sociedade. Tal crescimento torna mais necessrio a deniao de a c diretrizes para a obtenao de implementaoes seguras e ecientes de programas concorrentes, c c uma vez que a complexidade de implementaao e testes em ambientes concorrentes maior c e que em ambientes seq enciais. Este artigo dene diretrizes para o controle de concorrncia em u e sistemas orientados a objetos escritos em Java e que utilizam banco de dados relacionais. Em particular, mostramos como e onde os recursos da linguagem de programaao de do banco de c dados podem ser utilizados para controle de concorrncia. O objetivo principal das diretrizes e e garantir a corretude do sistema sem redundncia no controle de concorrncia, tanto aumentando a e a performance quanto garantindo a segurana do sistema. c

Introduo ca

Com o advento de sistemas de informaao baseados na World Wide Web temos um grande c impacto dos programas concorrentes na sociedade. De fato, ambientes concorrentes elevam consideravelmente a complexidade de implementaao e testes dos sistemas, uma vez c

Apoiado pela CAPES. Email: scbs@cin.ufpe.br. Apoiado em parte pelo CNPq, processo 521994/969. Email: phmb@cin.ufpe.br.

que erros sutis de implementaao levam a mau funcionamento de programas que podem c ser dif ceis de detectar. Este cenrio indica que precisamos de meios mais adequados para a implementaao a c de programas concorrentes, como a deniao de diretrizes que dem suporte ao controle c e de concorrncia nos sistemas, evitando que sejam feitos controles baseados na intuiao do e c programador. Tais controles podem ter um impacto negativo em ecincia, alm de no e e a garantir a segurana do sistema com relaao ao acesso concorrente ao mesmo. Alm disso, c c e controles baseados na intuiao tambm podem introduzir novas situaoes de corrida (race c e c conditions) que podem gerar execuoes invlidas do sistema em ambientes concorrentes. c a Alm de garantir a segurana, a deniao das diretrizes documenta e, portanto, padroniza e c c o controle a ser aplicado, favorecendo tambm a extensibilidade do sistema, uma vez que e melhora a manutenibilidade do mesmo. Atualmente a maioria dos sistemas utiliza sistemas gerenciadores de banco de dados (SGBD) para garantir a persistncia dos seus dados. Um SGBD deve garantir uma srie e e de caracter sticas, como a atomicidade e o isolamento das operaoes realizadas pelos mesc mos [8]. Estas caracter sticas fazem com que os SGBDs realizem controle de concorrncia, e de modo que duas operaoes de acesso aos dados no interram entre si mantendo a conc a sistncia dos dados. Alm disso, os SGBDs fornecem o servio de transaao, que garante e e c c a execuao atmica de uma seqncia operaoes. Logo, o SGBD pode ser visto como um c o ue c mecanismo para tratar parte da concorrncia nos sistemas, a concorrncia de acesso aos e e dados armazenado no mesmo. Neste trabalho utilizamos a linguagem Java [10] que orientada a objetos e pere mite programaao concorrente, fornecendo recursos para controlar uxos de execuoes c c concorrentes. Nas denioes das diretrizes utilizamos principalmente o modicador de c mtodos synchronized, que impede a execuao concorrente dos mtodos sincronizados e c e de um mesmo objeto. Outros recursos fornecidos pela linguagem, como os mtodos wait e e notify, so utilizados para aumentar a ecincia do controle em determinadas situaoes. a e c Com estes dois mecanismos dispon veis (linguagem de programaao e SGBD), surge c a d vida de qual destes utilizar para tratar concorrncia, ou em que casos cada um deve u e ser utilizado, de modo a garantir a corretude do sistema sem realizar controles redundantes. Este exatamente o ponto que procuramos elucidar neste trabalho. De fato, e denimos que controles de concorrncia devem ser deixados a cargo do SGBD e que cone troles devem utilizar os recursos da linguagem, indicando qual mecanismo de controle e em que partes do cdigo utilizlo. Estas denioes foram feitas baseadas em uma arquio a c tetura de software espec ca. De posse dos resultados apresentados, programadores tm e um guia importante para o controle de concorrncia, garantindo segurana e ecincia e c e na execuao dos sistemas. Atualmente podemos encontrar vrios trabalhos que se prec a ocupam em garantir ganhos de performance eliminando sincronizaoes desnecessrias de c a programas concorrentes em Java [3, 1, 7]. Nestes trabalhos podemos observar o impacto negativo em ecincia causado pelos mecanismos da linguagem de programaao Java, o e c que mostra a necessidade de guias para termos um controle de concorrncia correto e e eciente. Este artigo est organizado em cinco seoes. Na Seao 2 apresentamos uma arquitetura a c c de software e os tipos de classe que implementam a mesma utilizando padres de proo jeto [9, 6]. Em seguida, na Seao 3, denimos as diretrizes para controle de concorrncia c e com o intuito de garantir segurana e ecincia de execuao, alm de identicar quais c e c e dos mecanismos (SGBD e linguagem de programaao) utilizar para evitar determinadas c situaoes de corrida. Mostramos o impacto em performance de controles diferentes para c 2

concorrncia na Seao 4, e por m, na Seao 5, apresentamos as concluses e relacionamos e c c o nosso trabalho com outros.

Arquitetura de software e concorrncia e

As diretrizes apresentadas neste artigo foram denidas para serem utilizadas em sistemas com uma arquitetura de camadas espec ca e em padres de projetos [9, 6] que garantem o a estruturaao do sistema segundo a mesma. Esta arquitetura de camadas visa separar c os aspectos de dados, negcio, comunicaao (distribuiao) e apresentaao (interface com o c c c usurio), como mostrado na Figura 1. Tal estruturaao, evita o entrelaamento de cdigo a c c o com diferentes propsitos, por exemplo, cdigo de negcio e de dados, e juntamente com o o o os padres de projeto permite alcanar maiores n o c veis de reuso e extensibilidade.

Figura 1: Exemplos de arquitetura em camadas. Caso os sistemas no tenham esta estruturaao lgica, provavelmente haver um ena c o a trelaamento de cdigo com diferentes propsitos, dicultando o reuso e a extensibilidade. c o o De fato, sistemas sem esta estruturaao lgica, podem trabalhar diretamente com tabelas c o de um banco de dados relacional, sem modelar os dados manipulados pelo mesmo como objetos, apesar de utilizar linguagens de programaao orientadas a objetos. Nestes sistec mas, o controle de concorrncia deve car completamente a cargo do SGBD, uma vez que e requisioes feitas pelo usurio so passadas diretamente ao SGBD, no havendo criaao e c a a a c manipulaao de objetos. c Na Figura 2 apresentamos um diagrama de classes de UML [4] que descreve, de maneira geral, como se dispe as classes da arquitetura de software utilizada na deniao das o c diretrizes para controle de concorrncia. Esta arquitetura foi originalmente denida em e outro trabalho [18], tendo sido feitas aqui apenas algumas alteraoes. c Na seao seguinte explicamos o papel de cada tipo de classe mostrada na Figura 2 e c denimos as diretrizes para controle de concorrncia. Mais detalhes sobre a arquitetura e podem ser encontrados em outros trabalhos [16, 2, 13], incluindo variaoes e restrioes c c aplicadas em determinados tipos de sistemas.

Diretrizes para controle de concorrncia e

Nesta seao indicamos que mecanismos de controle utilizar (linguagem de programaao c c ou SGBD) e em que partes do cdigo cada um deve ser utilizado, de forma a termos o um controle seguro, no redundante e eciente. Para isso denimos diretrizes gerais para a o controle, e diretrizes espec cas para cada tipo de classe da arquitetura apresentada 3

Figura 2: Viso geral do padro de projeto. a a

na Seao 2. A deniao destas diretrizes evita controles ingnuos como sincronizar toc c e dos os mtodos de acesso ao sistema (mtodos da classe fachada), feito com os recursos e e da linguagem, ou implementar transaoes em todos os mtodos da classe fachada, feito c e com recursos do SGBD. No nal desta seao apresentamos os controles mais comumente c aplicados segundo nossa experincia, adquirida na implementaao e na anlise de vrios e c a a sistemas implementados conforme a arquitetura de software utilizada na deniao das c diretrizes.

3.1

Diretrizes gerais

Na deniao das diretrizes gerais procuramos controlar a concorrncia sofrida por qualquer c e um dos tipos de classe ilustrados na Figura 2. Denimos diretrizes que visam impedir a execuao concorrente de mtodos no atmicos, e de mtodos que lem os atributos c e a o e e alterados pelos mtodos no atmicos. Um mtodo no atmico o mtodo que possui e a o e a o e e mais de um comando, ou um comando que no executado atomicamente, atribuioes a e c entre variveis de alguns tipos, por exemplo. Estes mtodos podem sofrer interleaving [11, a e 15], ou seja, execuoes concorrente do mesmo podem se entrelaar entre si, ou entre c c execuoes de outro mtodo. Um exemplo deste tipo de mtodo so os que alteram e os c e e a que lem atributos dos tipos long ou double, j que a especicaao de Java [10] no e a c a garante a atomicidade na atribuiao a variveis destes tipos. Desta forma tais mtodos c a e deveriam utilizar um recurso da linguagem para impedir sua execuao. Java oferece o c modicador de mtodos synchronized que impede a execuao concorrente dos mtodos e c e 4

sincronizados de um objeto. Observe que estas diretrizes devem ser aplicadas em classes cujos objetos sofrem acesso concorrente, de modo a impedir a execuao concorrente de mtodos que no so executac e a a dos atomicamente e lem ou alteram atributos da sua classe. Mais exemplos destes tipos e de mtodos so descritos em outro trabalho [12]. e a

3.2

Diretrizes para Classes Bsicas de Negcio a o

Agora, denimos as diretrizes espec cas para as classes bsicas de negcio, as quais rea o presentam os objetos (bsicos) do sistema, como clientes e contas. Inicialmente devemos a identicar quais so as classes bsicas cujos objetos sofrem acesso concorrente. As coleoes a a c de dados tm papel determinante nesta identicaao, uma vez que estas classes so as rese c a ponsveis pelo armazenamento e recuperaao de instncias das classes bsicas de negcio. a c a a o Existem dois tipos de coleoes de dados: as volteis, que mantm os objetos em memria, c a e o e as persistentes, que armazenam os objetos em meio persistente. Normalmente, nas implementaoes das coleoes persistentes que utilizam um SGBD relacional (SGBDR), c c e criada uma instncia com os dados obtidos do SGBDR ao ser requisitado a recuperaao de a c um determinado objeto. Por exemplo, considere a implementaao do mtodo procurar c e da coleao de dados RepositorioContasBDR que utiliza a classe java.sql.ResultSet [14] c (linhas 2, 7, e 8), da API JDBC [19], para recuperar a resposta de um comando SQL (linhas 4, e 5) e criar uma instncia de Conta com os dados obtidos (linhas 7, e 8). A a classe ResultSet representa a tabela de resposta gerada pela execuao de um comando c SELECT no SGBDR. public class RepositorioContasBDR implements RepositorioContas { // . . . public Conta procurar(String numero) { Conta resposta = null; ResultSet rs = null; try { String query = "SELECT * FROM CONTAS " + "WHERE numero=" + numero + ""; // . . . resposta = new Conta(rs.getString("numero"), rs.getDouble("saldo")); } // . . . return resposta; } }

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:

Observe que a cada execuao o mtodo cria uma nova instncia de Conta (linhas 7 e c e a 8). Assim, caso dois threads requisitem uma consulta a uma mesma Conta, os mesmos recebero referncias para cpias distintas do objeto armazenado no SGBDR. Desta forma, a e o no h acesso concorrente aos objetos da classe Conta. a a Porm, implementaoes alternativas das coleoes de dados podem utilizar caches de e c c objetos, para garantir que nunca existir em memria mais de uma cpia de um objeto a o o armazenado no banco. Esta abordagem de caches utilizada por APIs de acesso a SGBDs e 5

relacionais1 e orientados a objetos (SGBDOO) [17], o que feito para evitar inconsistncias e e que podem acontecer, por exemplo, no caso de uma atualizaao concorrente de cpias de c o um mesmo objeto. Logo, duas requisioes para consultar um mesmo objeto recebero c a a mesma referncia para o objeto armazenado na cache. Desta forma, o objeto poder e a ser acessado concorrentemente, o que acontece, por exemplo, quando dois usurios esto a a usando o sistema ao mesmo tempo e solicitam, via a interface com o usurio, a alteraao a c de um mesmo objeto. Diretrizes Tendo identicado que objetos bsicos sofrem acesso concorrente devemos ento aplicar a a as diretrizes gerais nas classes destes objetos bsicos. Nas classes bsicas cujos objetos a a no sofrem acesso concorrente devemos apenas analisar situaoes em que no devem ser a c a permitidas atualizaoes concorrentes de cpias de um mesmo objeto. Por exemplo, conc o sidere o mesmo exemplo de aplicaao bancria citada anteriormente. A classe Conta tem c a mtodos como creditar e debitar. Na implementaao destes mtodos o saldo atualie c e e zado baseado no valor anterior do mesmo. Em se tratando da atualizaao concorrente de c duas cpias de um mesmo objeto, este tipo de operaao pode levar o objeto em questo a o c a um estado inconsistente. Por exemplo, considere uma poss execuao onde o saldo de vel c cpias de um mesmo objeto da classe Conta alterado concorrentemente executando o o e mtodo creditar e onde o operador executa dois blocos concorrentemente. Ao falarmos e em execuao concorrente de dois blocos queremos dizer que as execuoes dos mesmos se c c d de forma entrelaada, ou seja, h um interleaving [11, 15] na execuao dos dois blocos. a c a c Vamos adotar a convenao de que a execuao do bloco a esquerda do operador ser feita c c ` a por um thread chamado t1 e a execuao do bloco a direita por um thread chamado t2. c ` RepositorioContasBDR rep // . . . Conta c = rep.procurar(2287); Conta c = rep.procurar(2287); c.creditar(100); c.creditar(50); rep.atualizar(c); rep.atualizar(c); Neste caso, dois threads executariam concorrentemente as seguintes operaoes: procuc rar por uma mesma Conta em uma coleao de dados (que retorna cpias distintas para c o duas consultas pelo mesmo objeto), creditar um valor na Conta retornada pela consulta e atualizar a mesma na coleao de dados. No nal desta execuao a informaao do saldo c c c da conta pode estar inconsistente. De fato, esta execuao faz com que duas cpias sejam c o recuperadas e que a primeira cpia da Conta que for atualizada seja sobrescrita pela seo gunda. Desta forma, o valor nal do saldo ser inconsistente, pois ao invs de termos a e como resultado a atualizaao do atributo saldo da Conta com a soma dos crditos (150), c e teremos o saldo acrescido de apenas um dos crditos realizados (100 ou 50), dependendo e da ordem em que as cpias foram atualizadas. Logo, conclu o mos que tais atualizaoes c devem ser evitadas. A soluao que sugerimos para corrigir problemas em atualizaoes concorrentes de c c cpias de objetos implementar um controle de atualizaao para cada objeto, o que seria o e c feito no SGBD adicionando um timestamp [8] a todos os objeto. Este atributo informa a data e a hora da ultima atualizaao do objeto. A atualizaao de um objeto s per c c oe mitida se uma cpia do objeto no tiver sido atualizada mais recentemente. Alm disso, o a e
1

A API de JDBC no implementa caches e a mais comum atualmente. a e

o mtodo atualizar da coleao de dados, que verica se existe um objeto mais recentee c mente atualizado, deve ser sincronizado de modo a garantir a atomicidade da operaao. c Note que esta soluao utiliza tanto um recurso de controle de concorrncia da linguagem c e (na sincronizaao do mtodo atualizar), quanto o SGBD para armazenar os timestamps. c e Este mesmo controle pode ser feito em outras situaoes onde a atualizaao concorrente c c de cpias de um mesmo objeto deva ser evitada. Para identicar tais situaoes devemos o c considerar se, no sistema em questo, a atualizaao concorrente de duas cpias de objetos a c o de uma classe deve ser evitada. Ou seja, devemos identicar se, segundo os requisitos do sistema, esta atualizaao concorrente uma execuao invlida, devendo ser evitada, ou se c e c a da natureza do sistema. Um exemplo disso a classe Pessoa que possui apenas nome e e e cpf como atributos. Dependendo dos requisitos do sistema, a atualizaao concorrente do c atributo nome de cpias de uma mesma Pessoa pode ser, ou no, uma execuao invlida. o a c a Em geral, este tipo de situaao seria considerada vlida, uma vez que estas atualizaoes c a c que aconteceram concorrentemente poderiam acontecer minutos ou horas uma aps a ouo tra, e ainda assim o resultado seria o mesmo, o atributo nome seria atualizado com o valor da ultima atualizaao. c

3.3

Diretrizes para as Classes Coleo de Dados ca

Como dito na subseao anterior as coleoes de dados so responsveis pelo armazenamento c c a a e recuperaao dos objetos bsicos do sistema. As coleoes de dados possuem uma interface c a c (interface negciodados) que abstrai a forma de armazenamento dos dados. o Nas coleoes de dados persistentes, tambm podemos encontrar problemas de conc e corrncia no instante da incluso, atualizaao e remoao de um objeto no mecanismo de e a c c persistncia que o armazena. Nestes casos, devemos garantir que os recursos do SGBD, e ou de um outro mecanismo de persistncia, so utilizados de maneira correta; assim s e a o devemos incluir, atualizar ou remover um objeto do sistema dentro de uma transaao. De c fato, quando a coleao de dados em anlise trabalha com um SGBD, podemos assumir que c a grande parte do controle de concorrncia, no tocante a atualizaao dos dados, feito pelo e c e prprio SGBD. Nos resta apenas garantir que a implementaao dos mtodos seja atmica o c e o no que diz respeito ao acesso ao SGBD. Isto feito implementando o acesso ao SGBD e com apenas um comando SQL, ou implementando uma transaao em alguns mtodos da c e fachada, utilizando os servios da interface mecanismo de persistncia. Para garantir a c e atomicidade dos mtodos da coleao de dados devemos seguir os seguintes passos: e c Identicar os mtodos das coleoes de dados que direta ou indiretamente executam e c mais de um comando SQL; Identicar os mtodos das coleoes de negcio que chamam os mtodos das coleoes e c o e c de dados identicados no passo anterior; Identicar que mtodos da fachada chamam os mtodos das coleoes de negcio e e c o identicados no passo anterior; Os mtodos da fachada identicados no ultimo passo devem utilizar os mtodos e e iniciarTransacao, confirmarTransacao e cancelarTransacao, da interface mecanismo de persistncia, para implementar uma transaao na sua execuao. e c c Um exemplo de como um mtodo pode ser implementado como uma transaoes pode e c ser visto no mtodo atualizar da classe Fachada, onde os trechos de cdigo sublinhados e o so os responsveis pela implementaao da transaao. a a c c 7

public class Fachada { private CadastroContas contas; private MecanismoPersistencia mp; // . . . public void atualizar (Conta conta) { try { mp.iniciarTransacao(); contas.atualizar(conta); mp.confirmarTransacao(); } catch (TransacaoBDException ex) { mp.cancelarTransacao(); } } } A interface MecanismoPersistencia dene servios como o estabelecimento de coc nexo, implementaao de transaoes e obtenao de um canal de comunicaao 2 com o a c c c c mecanismo de persistncia. e Normalmente tambm existem as coleoes de dados volteis que so utilizadas apenas e c a a como respostas pelas consultas das coleoes de dados persistentes que retornam mais de c um objeto. No necessrio nenhum controle nestas coleoes, uma vez que as mesmas a e a c no sofrem acesso concorrente. a

3.4

Diretrizes para Classes Coleo de Negcio e Fachada ca o

As classes coleao de negcio so responsveis pelas vericaoes e validaoes segundo a c o a a c c pol tica da aplicaao. Tais classes utilizam os servios das interfaces negciodados para c c o armazenar e recuperar os objetos das classes bsicas. A classe fachada de negcio [9] a o prov uma interface unicada para todos os servios do sistema, centralizando todas as e c instncias das classes coleao de negcio. Note que a interface com o usurio deve utilizar a c o a o sistema atravs dos servios da fachada (Figura 2). e c Por m, denimos as diretrizes espec cas para as classes coleao de negcio e fachada. c o Nestas classes a principal preocupaao identicar regras de negcio que levem a situaoes c e o c de corrida. Um exemplo deste tipo de regra a vericaao, antes de incluir um objeto e c em uma coleao, se existe algum objeto com o mesmo cdigo do objeto a ser cadastrado. c o Em uma poss execuao concorrente que tenta cadastrar dois objetos com um mesmo vel c cdigo, ambos os threads fariam a consulta, receberiam a resposta de que no h nenhum o a a objeto com o mesmo cdigo dos a serem inseridos, e tentariam inserir os objetos. Desta o forma, o sistema caria em um estado inconsistente, uma vez que seria violada uma regra de negcio, ou seria gerado um erro inesperado. Neste caso espec o co, podese implementar uma geraao automtica de cdigo para os objetos, por exemplo, utilizando c a o o recurso de sequence do SGBDR, ou implementando tal recurso na prpria coleao de o c negcio. Assim esta vericaao de negcio no seria mais necessria. o c o a a Para outras vericaoes de negcio que gerem situaoes como a descrita anteriormente, c o c devemos evitar a execuao concorrente, sincronizando os mtodos responsveis pelas mesc e a
O canal de comunicaao da interface mecanismo de persistncia do tipo java.lang.Object. Cada c e e implementaao da interface deve denir o tipo espec c co do seu canal de comunicaao. c
2

mas, ou utilizando um gerenciador de concorrncia [16]. O gerenciador de concorrncia e e mantm um conjunto de String, e tem um mtodo iniciaExecucao, que recebe como e e parmetro um String e caso o mesmo j esteja no conjunto bloqueia a execuao deste a a c thread (que est executando o mtodo). Desta forma, podemos evitar execuoes concora e c rentes sobre um mesmo String, por exemplo, um mesmo cdigo de objeto, at que o o e thread que est executando utilizando o String, libere o thread que est bloqueado. Isto a a feito pela execuao do mtodo finalizarExecucao, avisando que terminou a execuao e c e c sobre um dado String. Devem ser criadas vrias instncias do gerenciador de concorrncia. De fato, em geral a a e h uma instncia do gerenciador por objeto das coleoes de negcio. Alm disso, em uma a a c o e mesma coleao pode existir mais de uma instncia do gerenciador. Isto pode acontecer c a no caso em que os mtodos de uma coleao possam executar concorrentemente entre si, e c mas no cada um separadamente, onde ter a amos um objeto gerenciador por mtodo. e Caso as coleoes de negcio, ou a classe fachada tenham algum outro atributo alm, c o e respectivamente, da interfacenegcio dados e da coleao de negcio, as diretrizes gerais o c o devem ser adicionalmente aplicadas nas mesmas.

3.5

Outras diretrizes

Denimos tambm diretrizes para a classe mecanismo de persistncia, que implementa e e a interface MecanismoPersistencia. Resumidamente, na deniao das diretrizes para c a classe mecanismo de persistncia devem ser aplicadas as diretrizes gerais. Estas diree trizes no so apresentadas pela limitaao no tamanho do artigo e para permitir uma a a c apresentaao mais didtica das demais diretrizes. Alm disso, a classe mecanismo de c a e persistncia s alterada ou se cria uma nova caso mude o mecanismo de persistncia utie oe e lizado. A classe reusada em vrios projetos, portanto suas diretrizes no so aplicadas e a a a nos mesmos, da a escolha por omitir detalhes sobre estas diretrizes.

3.6

Controles mais comumente aplicados

Depois de implementar e analisar vrios sistemas implementados segundo a mesma arquia tetura de camadas e os mesmos padres de projetos apresentados aqui, podemos identio car quais controles de concorrncia so mais comuns, ou seja, so aplicados com maior e a a freqncia. ue Normalmente apenas a implementaao de transaoes feita na classe fachada e nec c e nhum outro controle necessrio nesta classe. Nas coleoes de negcio existem algumas e a c o chamadas aos mtodos do gerenciador de concorrncia para evitar interferncias causadas e e e por regras de negcio. A sincronizaao de mtodos feita apenas nos mtodos de atuo c e e e alizaao das coleoes de dados que implementam a tcnica de timestamp, ou em alguns c c e mtodos das coleoes de negcio que no utilizam o gerenciador de concorrncia caso o sise c o a e tema mesmo tenha poucos usurios simultneos acessando o sistema e caso estes mtodos a a e tenham pequeno peso computacional, conforme mostramos na seao seguinte. Nas classes c bsicas, o controle se resume a implementaao da tcnica de timestamp, que adiciona o a ` c e atributo timestamp, e os mtodos de acesso ao mesmo, sem nenhum controle adicional, e uma vez que na maioria dos sistemas os objetos bsicos no sofrem acesso concorrente a a devido as implementaoes das coleoes de dados persistentes. Esta a nossa alternativa ` c c e para controles intuitivos que tendem a sincronizar e implementar transaoes em todos os c mtodos da classe fachada. e 9

Impacto das diretrizes em performance

Nesta seao relatamos e analisamos testes de ecincia feitos com diferentes diretrizes e c e abordagens de controles de concorrncia, incluindo as estudadas e utilizadas na elaboraao e c das diretrizes denidas neste trabalho. Os resultados destes testes mostram que algumas abordagens no so recomendadas, mostrando a vantagem da abordagem sugerida pelas a a nossas diretrizes. Alm disso, os resultados dos testes auxiliam na deciso de que altere a nativa usar no controle, uma vez que, em alguns casos, as nossas diretrizes sugerem mais de uma soluao. c

4.1

Preparao dos testes ca

Para realizar os testes, implementamos um pequeno sistema de cadastro de clientes, que permite cadastrar, procurar e atualizar objetos. Os testes realizam operaoes de incluso, c a consulta, e alteraao feitas em diferentes verses do sistema, cada uma com um dos c o diferentes controles de concorrncia analisados. Realizamos trs comparaoes. A primeira e e c compara os seguintes controles: Nenhum controle: Sistema sem nenhum controle de concorrncia; e Fachada sincronizada: Todos os mtodos da classe fachada sincronizados; e Fachada com transaoes: Todos os mtodos da classe fachada implementando transaoes; c e c Controle sugerido: Aplicando as diretrizes denidas neste trabalho, com gerenciador de concorrncia na coleao de negcio e timestamp para a classe Pessoa. e c o Dos quais apenas a abordagem de sincronizar toda a fachada e a que aplica as diretrizes que denimos garantem a corretude dos sistemas se aplicadas isoladamente. A abordagem que no realiza nenhum controle utilizada para servir de referncia na comparaao com a e e c os demais controles. A segunda comparaao procura medir o impacto da tcnica de c e timestamp onde comparamos as seguintes verses do sistema: o Nenhum controle: Sistema sem nenhum controle de concorrncia; e Timestamp: Tcnica de timestamp [16] implementado para a classe bsica Pessoa; e a Por m, analisamos a alternativa que denimos para a sincronizaao de mtodos comc e parando as seguintes verses do sistema: o Sincronizaao nas Coleoes de Negcio: Mtodo cadastrar da coleao de negcio c c o e c o sincronizado; Gerenciador de Concorrncia nas Coleoes de Negcio: Mtodo cadastrar da coleao e c o e c de negcio utilizando a classe GerenciadorConcorrencia [16]; o Para cada um dos diferentes tipos de controle, analisamos tambm variaoes nos e c mtodos que receberam tal controle. Assim, pudemos aferir o impacto que diferentes e tipos de sistema (representados pelas variaoes utilizadas) tm em diferentes controles. O c e aumento do tempo de execuao, peso computacional, de um mtodo foi implementado c e atravs da incluso de um loop nos mtodos tratados, aumentando o tempo de execuao e a e c dos mtodos originais em aproximadamente 100%. e 10

Outra variaao nos testes realizados foi um aumento na carga do sistema. Realizamos c testes com vrias cargas entre 3 e 600 threads acessando o sistema concorrentemente. Com a isto pudemos simular uma situaao de concorrncia extrema, dicilmente encontrada nos c e picos de acesso em sistemas reais. Por exemplo, dados coletados por um sistema web de mdio porte, com uma taxa razovel de acesso, tm picos de acesso que no ultrapassam e a e a 400 usurios por hora (os tempos de execuao dos nossos experimentos so de alguns a c a segundos). Nossos testes foram realizados utilizando o SGBDR Oracle 8.04, com 12 canais de comunicaao dispon c veis na classe mecanismo de persistncia. A mquina que executa e a o SGBDR um Power RS6000 39H (IBM) com 512 MB de memria RAM, rodando o e o sistema operacional Unix AIX 4.2. A mquina utilizada para executar o sistema teste e a a criaao de threads simulando o acesso concorrente ao sistema um PC AMD K6-2 500 c e MHz, com 128 MB de memria RAM, executando o Windows NT 4.0. Foi utilizado o o JDK1.2V para compilar e executar os testes.

4.2

Anlise dos testes de performance a

A seguir resumimos os testes de ecincia realizados com as diferentes variaoes como e c carga do sistema e peso de execuao dos mtodos. c e Abordagens gerais para controle de concorrncia e A Figura 3 apresenta um grco de barra que mostra o impacto, em relaao ao sistema a c sem nenhum controle, de sincronizar todos os mtodos da fachada, implementar todos os e mtodos da fachada como transaoes, e aplicar as diretrizes sugeridas neste artigo. e c

Figura 3: Impacto de diferentes controles de concorrncia. e Olhando o grco, o controle que sincroniza todos os mtodos da fachada bem caro, a e e chegando a aumentar o tempo de execuao em cerca de 120%. Podemos ainda perceber c um overhead signicativo, mais de 50%, na implementaao do conceito de transaoes em c c todos os mtodos da fachada. Isto nos motiva a aplicar as nossas diretrizes para controle e de concorrncia, as quais indicam, alm de outros controles, exatamente que mtodos da e e e fachada devem implementar transaoes. Em relaao ao impacto causado pela aplicaao c c c das diretrizes denidas neste trabalho, podemos concluir que o impacto pequeno (menos e de 10%), se comparado com as demais abordagens. Todavia, este um impacto necessrio e a para garantir a segurana e o bom funcionamento do sistema. c 11

Alm disto, nos tempos de execuao de mtodos pesados observamos que houve uma e c e diminuiao no impacto dos controles em at mais de 50%, o que nos leva a concluir que c e quanto mais pesados forem os mtodos de um sistema, menor ser o impacto do controle e a no tempo de execuao do mesmo. c Timestamp Similar ao que zemos na comparaao anterior, podemos observar na Figura 4 o impacto c de aplicar a tcnica de timestamp comparado ao sistema sem nenhum controle. O impacto e pequeno, menos de 10%, no caso de mtodos leves, mas em mtodos mais pesados o ime e e pacto maior, variando de 10% at quase 35%. Isto ocorre devido ao n mero de canais de e e u comunicaao que um fator limitante, neste caso; como os mtodos da coleao de dados c e e c so mais pesados, eles demoram mais a executar. Com isto eles acabam mantendo o canal a de comunicaao por um tempo maior, impedindo que outros threads o utilizem. Nestes c testes t nhamos 12 canais de comunicaao dispon c veis no mecanismo de persistncia. Noe vamente, apesar de observarmos um impacto considervel no caso de mtodos pesados, a e este um controle necessrio para garantir a corretude do sistema. e a

Figura 4: Impacto do timestamp.

Gerenciador de Concorrncia e A ultima comparaao feita foi entre a sincronizaao de mtodos da coleao de negcio e c c e c o a utilizaao de chamadas ao gerenciador de concorrncia nestes mtodos. Consideramos c e e mais uma varivel na realizaao destes testes. Alm da carga do sistema e do peso dos a c e mtodos, zemos testes onde ocorrem situaoes de corrida com relaao aos dados, para e c c que as soluoes sejam avaliadas segundo este aspecto. Nos outros testes no existia a conc a corrncia em relaao aos dados, ou seja, no eram inseridos, atualizados ou consultados e c a objetos com o mesmo cdigo concorrentemente. Fizemos mais esta variaao pois a mesma o c poderia sugerir a utilizaao de diferentes alternativas para cada caso, uma vez que esta c semntica dos mtodos utilizada pelo gerenciador de concorrncia para realizar a sina e e e cronizaao quando necessrio. Esta variaao foi implementada criando conjuntos threads c a c que tentam inserir, atualizar e consultar um mesmo objeto. A Figura 5 mostra o impacto de utilizar o modicador de mtodos synchronized, em e detrimento do gerenciador de concorrncia. Podemos observar que a sincronizaao dos e c mtodos com o modicador synchronized na coleao de negcio de 20% a 40% pior que a e c o e 12

utilizaao do gerenciador de concorrncia, a no ser no caso com poucos usurios acessando c e a a o sistema concorrentemente, onde os controles tm basicamente o mesmo impacto. Nos e casos em que as duas soluoes tm sempre o mesmo desempenho, ou seja, sistemas que s c e o so acessados por menos de 6 usurios simultaneamente, sugerimos a adoao da soluao a a c c que utiliza o modicador synchronized, uma vez que a mais simples de implementar e e manter. Nos testes com mtodos pesados o impacto do controle com o modicador e synchronized menor, mas ainda assim bem relevante cando ente 10% e 20%. e e

Figura 5: Impacto do synchronized em relaao ao gerenciador de concorrncia. c e

Concluses o

A implementaao de sistemas concorrentes dif devido a grande complexidade inserida c e cil pelo nodeterminismo inerente a este tipo de ambiente. Ao implementar um sistema que a deve executar em ambiente concorrente devemos controlar a concorrncia sofrida pelo e mesmo, de modo a evitar que interferncias indesejadas levem o sistema a um estado e inconsistente. Um problema ao realizar o controle de concorrncia identicar o melhor e e local para realizar determinados controles e que mecanismos utilizar em cada caso. Neste trabalho estamos considerando sistemas que utilizam banco de dados relacionais e a linguagem de programaao Java. Certamente os sistemas podem utilizar as caracter c sticas dos SGBDs para deixar parte do controle a cargo dos mesmos. A outra parte do controle deve ser feita com recursos da linguagem de programaao. Mas ainda existe a d vida de c u quais destes mecanismos utilizar e em que casos devem ser utilizados cada um de modo a evitar controles redundantes. Outra questo em que ponto do cdigo realizar o cona e o trole de modo a obter uma melhor ecincia na sua implementaao. Por isto de supra e c e importncia a deniao de diretrizes que dem suporte na implementaao de sistemas a c e c concorrentes fornecendo guias para a identicaao de que pontos controlar a concorrncia c e e qual mecanismo utilizar em cada caso. Sem d vida, qualquer controle que no utilize u a um padro documentado pass de erros. A deniao de que parte do controle deve ser a e vel c feita pelo SGBD e que parte deve ser feita pela linguagem evita redundncias, garantindo a ecincia de execuao do sistema, uma maior extensibilidade e mais produtividade no e c desenvolvimento. Isto sem falar dos problemas de extensibilidade e reuso que podem ser ocasionados pela falta de um padro para a implementaao. Certamente, a contribuiao a c c maior deste artigo a deniao das diretrizes para o controle de concorrncia em sistemas e c e implementados em Java com base na arquitetura e nos padres de projetos sugeridos pelo o 13

Pim [5] e que utilizem SGBDs relacionais, garantindo a corretude dos sistemas com o uso eciente dos controles. Em geral, o SGBD resolve boa parte do controle de concorrncia, eliminando a nee cessidade do uso de recursos da linguagem em vrios lugares, como nas classes bsicas, a a onde s deve ter controle por parte da linguagem caso seus objetos sofram acesso cono corrente, o que segundo nossa experincia no acontece na maioria dos sistemas. Mas os e a SGBDs no resolvem todos os problemas relacionados a controle, logo, precisamos saber a em que pontos necessrio o uso dos recursos da linguagem de modo a evitar controles e a redundantes e, portanto o impacto negativo em performance. Resolvemos tais problemas atravs da deniao de diretrizes de controle, evitando perdas de 10% a 110% quando e c comparadas com soluoes ingnuas como sincronizar os mtodos da classe fachada. As c e e diretrizes foram denidas para controlar concorrncia de maneira progressiva, ou seja, e aps a implementaao dos aspectos funcionais, de modo permitir que o programador no o c a se preocupe, inicialmente, com aspectos de controle de concorrncia. As diretrizes podem e tanto ser utilizadas para analisar sistemas onde j foi implementado o controle, de modo a a validar e corrigir, caso necessrio, o controle aplicado, quanto para tratar a concorrncia a e de maneira no progressiva, ou seja, ao mesmo tempo em que os requisitos funcionais do a sistema so implementados. a Neste artigo analisamos algumas alternativas para solucionar problemas de concorrncia e e mostramos que em geral o gerenciador de concorrncia se mostrou mais eciente que a e utilizaao do modicador synchronized. Alm disso, constatamos o impacto da utilizaao c e c desordenada do modicador de mtodos synchronized, bem como da implementaao dese c necessria de transaoes nos mtodos da classe fachada. Os experimentos tambm nos a c e e permitiram armar que o impacto da aplicaao das diretrizes em um sistema relativac e mente pequeno, apesar de ser um impacto necessrio. Outra vantagem da nossa proposta a que a mesma baseada em uma arquitetura de software espec e e ca, o que nos permite uma deniao e uma aplicaao mais exata das diretrizes dando mais suporte ao prograc c mador. Apesar de ser espec ca a arquitetura utilizada serve para a implementaao de c in meros sistemas. A produtividade favorecida pelo fato das diretrizes irem direto ao u e ponto, identicando em que classes e de que maneira podem surgir situaoes pass c veis de controle, alm, claro, de denir que mecanismo de controle e onde utilizlos em cada e e a caso. Um trabalho relacionado Concurrent Programming in Java [12] onde so propostos e a modelos para a implementaao de programas concorrentes em Java, so descritos padres c a o de projeto para organizar classes de maneira a garantir que o sistema seja executado com segurana em ambientes concorrentes e so denidas algumas regras para inserir e retirar a c a sincronizaao de mtodos ou trechos de cdigo. A abordagem descrita no trabalho sugere c e o que o controle deve ser aplicado durante a implementaao dos requisitos funcionais do c sistema, o que eleva a complexidade da implementaao por fazer com que o programador c se preocupe desde o in com o controle de concorrncia. Apesar de no ser o nosso cio e a objetivo, as nossas diretrizes tambm podem ser utilizadas com este propsito. Porm, o e o e diferencial do nosso trabalho o fato de nos basearmos em uma arquitetura de software e espec ca, o que facilita a deniao de diretrizes mais precisas, permitindo inclusive um c alto grau de automatizaao. Outro diferencial a deniao de regras e padres para c e c o tratar a concorrncia em sistemas que utilizam SGBDs relacionais, permitindo utilizar os e recursos para controle j fornecidos pelos mesmos. a

14

Resumo das diretrizes

1 1.1 1.2 1.3 1 2 3 1 2 2.1 2.2 3 3.1 3.2 3.3 3.4 1 2 3 1 2 Gerais Impedir execuoes concorrentes de mtodos no atmicos c e a o Mtodos que alteram e lem atributos dos tipos double e long e e Mtodos que utilizam valores dos atributos na realizaao das operaoes e c c Mtodos que realizam atribuioes a mais de um atributo e c Classes Bsicas de Negcio a o Identicar classes bsicas que sofrem acesso concorrente a Aplicar diretrizes gerais nas que sofrem acesso concorrente Evitar atualizaoes concorrentes de cpias de objetos (se necessrio) c o a Classes Coleoes de Dados c Identicar coleoes de dados que utilizam um SGBD c Garantir que operaoes que modicam o SGBD sejam atmicas c o Utilizar apenas um comando SQL por mtodo, ou e Implementar transaoes na classe fachada c Controlar a concorrncia sofrida pelas coleoes que no utilizam um SGBD e c a Impedir acesso concorrente a estruturas de dados em memria, ou o Utilizar estruturas de dados que suportem acesso concorrente thread safe Impedir acesso concorrente a outros meios de persistncia, e e Implementar o servio de transaoes para outros meios de persistncia c c e Classes Coleoes de Negcio e Fachada c o Sincronizar mtodos com regras de negcio que geram condioes de corrida e o c Utilizar o gerenciador de concorrncia aumentando a ecincia e e Implementar/utilizar a geraao automtica de cdigo (sequence) c a o Mecanismo de Persistncia e Impedir acesso concorrente a estruturas de dados em memria, ou o Utilizar estruturas thread safe

Agradecimentos
Este trabalho foi parcialmente nanciado pela CAPES e pelo CNPq, agncias nanciadoe ras de pesquisas brasileiras.

Referncias e
[1] Ole Agesen, David Detlefs, Alex Garthwaite, Ross Knippel, Y. S. Ramakrishna, and Derek White. An ecient meta-lock for implementing ubiquitous synchronization. In Proceedings of the 1999 ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 207222. ACM, November 1999. [2] Vander Alves. Progressive development of distributed object-oriented applications. Dissertaao de Mestrado, Centro de Informtica Universidade Federal de Pernamc a buco, Fevereiro 2001. [3] Je Bogda and Urs Hlzle. Removing unnecessary synchronization in java. In Proo ceedings of the 1999 ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 3546. ACM, November 1999. 15

[4] Grady Booch, Ivar Jacobson, and James Rumbaugh. Unied Modeling Language Users Guide. AddisonWesley, 1999. [5] Paulo Borba, Saulo Ara jo, Hednilson Bezerra, Marconi Lima, and Srgio Soares. u e Progressive Implementation of Distributed Java Applications. In Engineering Distributed Objects Workshop, ACM International Conference on Software Engineering, pages 4047, Los Angeles, EUA, 17th18th May 1999. [6] F. Busschmann, R. Meunier, H. Robert, P. Sommerlad, and M. Stal. A System of Patterns: PatternOriented Software Architecture. John Wiley & Sons, 1996. [7] Jong-Deok Choi, Manish Gupta, Mauricio Serrano, Vugranam C. Sreedhar, and Sam Midki. Escape analysis for Java. In Proceedings of the 1999 ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 119. ACM, November 1999. [8] Ramez Elmasri and Shamkant Navathe. AddisonWesley, second edition, 1994. Fundamentals of Database Systems.

[9] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable ObjectOriented Software. AddisonWesley, 1994. [10] James Gosling, Bill Joy, and Guy Steele. The Java Language Specication. Addison Wesley, second edition, 2000. [11] C.A.R. Hoare. Communicating Sequential Processes. Prentice Hall International Series in Computer Science, 1985. [12] Doug Lea. Concurrent Programming in Java. Addison-Wesley, second edition, 1999. [13] Tiago Massoni. Um Processo de Software com Suporte para Implementaao Proc gressiva. Dissertaao de Mestrado, Centro de Informtica Universidade Federal de c a Pernambuco, Fevereiro 2001. [14] Sun Microsystems. Package java.sql. Dispon em http://java.sun.com/products/ vel jdk/1.2/docs/api/java/sql/package-summary.html. [15] A.W. Roscoe. The Theory and Practice of Concurrency. Prentice-Hall, 1998. [16] Srgio Soares. Desenvolvimento Progressivo de Programas Concorrentes Orientados e a Objetos. Dissertaao de Mestrado, Centro de Informtica Universidade Federal de c a Pernambuco, Fevereiro 2001. Dispon em http://www.cin.ufpe.br/scbs/syscoop. vel [17] Ardent Software. O2 technology user manual: Java relational binding. Version 2.0, July 1997. [18] Euricelia Viana and Paulo Borba. Integrando Java com Bancos de Dados Relacionais. In III Simpsio Brasileiro de Linguagens de Programaao, pages 7791, Porto Alegre, o c Brasil, 57 de Maio 1999. [19] Seth White and Mark Hapner. JDBC 2.1 API. Version 1.1. Sun Microsystems, October 1999.

16