AUTORES: Edivaldo V. Santos & Saul Schead

O presente artigo tem por objetivo apresentar estratégias a fim de proporcionar aos usuários finais de aplicações baseadas em Banco de Dados, com acesso simultâneo e concorrente por diversos outros usuários, a possibilidade de terem suas aplicações client, notificadas quando os dados exibidos não mais corresponderem a realidade da base de dados do SGBD (Sistema Gerenciador de Bases de Dados, ou RDBMS em inglês), podendo dessa formar proceder a atualização das informações exibidas. A relevância se dá em preservar a atualidade, e veracidade da informação aos usuários e equipamentos, economizar recursos computacionais, gerar vantagens competitivas as organizações.

Quando se estuda, em termos reais, o desenvolvimento de sistemas baseados em SGBDs em que os requisitos dos sistemas estejam relacionados com a capacidade de manter atualizadas as consultas em tela de diversos usuários, com as alterações realizadas concorrentemente na base de dados, percebemos uma lacuna na literatura sobe como atender esse quesito. Essa lacuna é preenchida de forma não sistêmica, muitas vezes sem padronização, ou estudo das implicações que isso possa acarretar como veremos mais adiante, de forma geral a atualização nesses casos é realizada por “time” ou seja a cada “X” unidades de tempo procedesse a uma nova consulta (query) na base de dados, independente se houve, ou não, alterações na base consultada, na Figura 1 temos uma configuração Client-server típica, usada para exemplificar as situações que trataremos.

Client-Server

Figura 1. Client-Server

O desenvolvimento de maneira geral no tocante a sistemas de manipulação de dados, principalmente comerciais, tem características embasadas na literatura que lhe permitem a consistência dos dados no processamento de dados com SGBD (propriedades ACIDAtomicidade, Consistência, Isolamento e Durabilidade), porém essa eficiente abordagem, não isenta, apesar de manter a consistência dos dados, problemas na parte client de um sistema quanto a visualização dos dados. Tomando como exemplo um sistema de vendas de passagens áreas, onde duas pessoas não podem (não deveriam) comprar o mesmo assento em um mesmo vôo temos que caso ocorra alguma operação que viole esse escopo, teremos como resposta do sistema uma mensagem de erro do sistema, ao tentar completar a operação, mensagem essa oriunda de uma reposta do servidor (SGBD) em resposta a uma tentativa do client, de tentar realizar.

Pela ilustração anterior notamos ser possível que diferentes clients, possam estar visualizando dados oriundos da mesma consulta (Ex.: Assentos ocupados no vôo “Y”), e que os mesmos sejam diferentes, por exemplo, caso um client (ex. A) realize uma consulta, e após isso um outro client (ex. B) faça uma atualização imediatamente posterior a consulta do client “A”, tirando a disponibilidade do assento “alpha”, essa atualização não estará sendo espelhada no client“A” que realizou a primeira consulta, cujo o usuário nesse momento estará trabalhando com dados desatualizados, de forma que ele só se dará conta quando solicitar uma nova consulta a esses dados, ou, quando receber uma mensagem de erro por infligir alguma regra de negócio imposta ao SGBD, por exemplo tentar reservar o assento que já foi reservado,pois os dados não mais refletiam a disponibilidade de assentos por ele visualizada.

A necessidade de atualizações, para que tenhamos nos clients a visualização de dados que reflitam a real situação das informações a cada atualização, ou o mais próximo disso, com o menor custo computacional é um assunto recorrente de vários estudos e tecnologias.Para ilustrar a busca desse objetivo temos o exemplo de ÁjaxAsysnchronus JavaScript and XML, componente da nova geração de aplicativos Web 2.0 [O’Reilly, 2005] e que segundo Garret[2005] é um conjunto de tecnologias que evolui por si própria, permitindo a atualização de partes de páginas web, por exemplo formulários, de forma a poupar os recursos computacionais, largura de rede e proporcionar uma resposta mais rápida aos usuários que se utilizam desse tipo de client web.

Tecnologias com esse foco têm um amplo leque de aplicações em diversos campos: Medicina, as informações médicas dos pacientes, oriundas de bases de dados heterogêneas (prontuários eletrônicos em um sistema hospitalar e/ou exames ou monitoramento dos mesmos via equipamentos remotos) poderiam gerar respostas automáticas; Companhias que trabalham com movimentação de títulos em diversos mercados diferentes; Acompanhamento de eleições..., etc, são alguns exemplos possíveis, que permitem agregar valor aos sistemas com a utilização de práticas dessa natureza.

Novas técnicas nesse sentindo teriam um maior ganho se pudesse selecionar quando atualizar, e que clients atualizar, ou decidir entre enviar a informação já processada ou apenas um aviso de que a informação na tela do client se encontra desatualizada. Essas diferenças poderiam ser tratadas tanto em função dos recursos computacionais disponíveis quanto em função das regras de negócio. Até mesmo a atualização de bases de dados distribuídas por “snapshot” poderiam se beneficiar de tais técnicas, aumentando o período que elas necessitariam de ser atualizadas por completo, transferindos novos “snapshots”.

Proposta de Métodos de Atualização de Visualização de Consultas em Clients conectados a um SGBD, quando da atualização de dados na base acessada.

Um conceito muitas vezes pouco abordado na concepção de sistemas com a integração de SGBD é o do gerenciador de comunicações de dados (DC - Data Communications), que é tido como um sistema autônomo com relação ao SGBD, mas que necessita trabalhar em sincronia com o mesmo, para que o DC possa executar sua tarefa, nesse caso,enviar mensagens mantendo os clients atualizados com relação ao último estado consistente do SGBD.

Talvez seja novidade para alguns, mas vários SGBDS possuem um sistema de evento, baseado em triggers que permitem ao mesmo enviar, entre sessões diferentes do SGBD, avisos de alterações na base de dados. Existem diversos SGBDs, comerciais ou não, que disponibilizam essas funcionalidades em seus frameworks, como exemplo temos o Interbase, que pode ser acessado via aplicações desenvolvidas em Delphi, linguagem/ IDE desenvolvida pelo mesmo fabricante do SGBD, por meio de componentes IBevent, que gera notificações enviadas pelo SGBD com relação a alguma alteração na base de dados previamente alertada pelo uso de procedures ou triggers, entretanto para acessar esse recursos de outros SGBD (por exemplo Oracle) o programador Delphi, tomado nesse momento como exemplo, deve adquirir um outros framework de componentes (por exemplo ODAC).

Propomos uma nova abordagem, com independência de SGBD e Linguagem de programação, de forma a utilizar praticamente qualquer SGBD com suporte a eventos, e pacotes de envio de mensagens via TCP/IP, procedures e triggers, podendo dessa maneira a enviar mensagens de atualização a seus clients conectados, sejam eles produzidos em qualquer linguagem de programação capaz de escutar (listerner) uma porta, atualmente quase todas as linguagens preenchem esses requisitos, de forma que é perfeitamente possível criar aplicativos que permitam a atualização de consultas em tempo real para visualização de consultas(Querys) pelos clients conectados a qualquer SGBD moderno.

Dessa maneira, nossa proposta se baseia na utilização de algumas propriedades e característica que devem existir nos SGBDs :

  • Suporte à eventos;
  • Suporte a comunicação, envio de mensagens, via TCP/IP.

No caso da linguagem do aplicativo Client, ele deverá ter a propriedade de “escutar” mensagens via TCP/IP, no exemplo usaremos uma comunicação por Sockets, de acordo com JAMES F KUROSE: “socket é a interface entre a camada de aplicação e a de transporte dentro de uma máquina”.

Os sockets são muito conhecidos por programadores de aplicativos para comunicação remota. Através de uma porta, você poderá conectar-se a outro computador ou aceitar conexões de outras máquinas. O que propomos é a comunicação pré-estabelecida entre o servidor (SGBD) e o client, de forma que o servidor, de conhecimento que um determinado client está conectado a ele, e que realizou determinada consulta, possa informar ao client caso sua base consultada tenha sofrido alterações, de forma a utilizar o mínimo de recursos computacionais. Podemos extrapolar as opções entre o envio de pacotes para atualização completa, ou envio de mensagem para que o client realize uma nova consulta ao servidor, algumas opções de se fazer isso, e seus ganhos potenciais:

OpçãoVantagemDesvantagem
Mandar uma mensagem do SGDB, de forma que o aplicativo solicite atualização, forçando uma nova query do cliente.- Facilidade de Implantação.- Maior número de Consultas contra o SGBD
Mandar uma mensagem via stream contendo as alterações realizadas- Menor número de consultas por parte dos cliente ao SGBD- Maior complexidade tanto no envio, quanto para atualização pelo cliente

Com a utilização dos SGBDs atuais, podemos ainda tanto realizar a consulta (Query) e guardar em “cache” no SGBD, para aumentar a performance, em relação a utilização de Disco e uso de CPU, quanto utilizar uma combinação de outras técnicas para melhor utilização dos recursos computacionais disponíveis, (cache do servidor(Sistema Operacional), atualização de cache de client, etc.).

Podemos visualizar a nossa proposta pela Figura 2.

estrutura

Figura 2. Estrutura

Cada client conectado ao SGBD, está “escutando” se ocorreu alguma atualização de dados a ele destinada, caso ele “escute” a mensagem, procederá a atualização da visualização para o usuário(realizando nova consulta ao SGBD ou utilizando a informação enviada diretamente em seu resultset).

Exemplo prático da utilização da metodologia proposta com a utilização de SGBD Oracle, servidor de Base de Dados, e Ferramenta de desenvolvimento Delphi, para confecção do Client.

Nosso exemplo é bastante simples, e se baseia em duas partes:

  1. Criação de um programa em Delphi(oprincipal.exe) que receberá a mensagem enviada via SGBDOracleTCP/IP.
  2. Criação da rotina em PL/SQLOracleque enviará a mensagem via TCP/IP para a estaçãoclientDelphi.

1.1) Criar uma tabela chamada LOG_ACESSO para guardar os dados de sessão doclientque está conectado no momento.

A tabela tem a seguinte estrutura:

CREATE TABLE LOG_ACESSO
(
  SID         NUMBER, 
  AUDSID      NUMBER,
  TERMINAL    VARCHAR2(30 BYTE),
  PROGRAM     VARCHAR2(48 BYTE),
  IP          VARCHAR2(15 BYTE),
  USERNAME    VARCHAR2(10 BYTE),
  PORT        NUMBER,
  LOGON_TIME  DATE);

Essa tabela armazena as informações de sessão dos usuários conectados ao SGBD, possibilitando o envio de mensagens somente aos clients que interessam, alguns testes que realizamos com a utilização de mensagens para todos osclientsou estações conectadas, tiveram um resultado negativo em relação a performance.

A segunda tabela criada, será objeto das atualizações que disparam o evento, nesse caso a tabela FUNCIONARIO, que será nosso exemplo prático:

CREATE TABLE  FUNCIONARIOS
(
  CODIGO  CHAR(10 BYTE),
  NOME    VARCHAR2(200 BYTE),
  FONE    CHAR(20 BYTE),
  EMAIL   VARCHAR2(20 BYTE)
);

1.2) Criar uma função em Delphi para capturar o número IP da máquina client que se conectam ao SGBD (Oracle):

 uses WinSock;Function TFrmSimulador.GetIPAddress: String;
 Type  Name = Array[0..100] Of Char;  
 PName = ^Name;Var  HEnt: pHostEnt;  HName: PName;  
 WSAData: TWSAData;  i: Integer;Begin  Result := '';  
 If WSAStartup($0101, WSAData) <> 0 Then   
  Exit; 
  New(HName); 
  If GetHostName(HName^, SizeOf(Name)) = 0 Then  
 Begin  
  HEnt := GetHostByName(HName^);    
  For i := 0 To HEnt^.h_length - 1 Do     
   Result :=        Concat(Result,       
    IntToStr(Ord(HEnt^.h_addr_list^[i])) + '.');    
   SetLength(Result, Length(Result) - 1);  
 End;  
 Dispose(HName);  
 WSACleanup;
End;

1.3) Criar na rotina client(Delphi) para gravar o log de acesso na tabela LOG_ACESSO, passando o número da porta que a aplicação vai “ouvir”.

OBS: Usamos o Componente TSQLConnection da palheta DbExpress para acesso ao banco de dados, o nome do componente é Conexao.

procedure TFrmSimulador.Grava_Log_Acesso(Porta: Integer);
var SqlTemp: TSQLQuery;
    Sid,AUDSID:integer;
    Programa,Terminal,Username:ShortString;
   begin
  SqlTemp:= TSQLQuery.Create(nil);
  SqlTemp.SQLConnection:=   Conexao;
  SqlTemp.SQL.Text:= 'SELECT PROGRAM,LOGON_TIME,SID,AUDSID,TERMINAL,USERNAME       ' +
  'FROM V$SESSION                        ' +
    'WHERE AUDSID=USERENV(''SESSIONID'')  ';
  SqlTemp.Open;
 
  Sid       := SqlTemp.FieldByName('sid').asInteger;
  AudSid    := SqlTemp.FieldByName('audsid').AsInteger;
  Terminal  := SqlTemp.Fieldbyname('terminal').asString;
  Username  := SqlTemp.FieldByName('username').asString;
  Programa  := SqlTemp.FieldByName('program').asString;
 
  SqlTemp.Close;
  SqlTemp.SQL.Clear;
 
  SqlTemp.Sql.Add('Insert into  LOG_ACESSO (Sid,AudSid,Terminal,Program,IP,Username,Port,Logon_Time) ');
  SqlTemp.Sql.Add('values (:sid,:audsid,:terminal,:program,:ip,:username,:port,sysdate)  ');
  SqlTemp.ParamByName('sid').asInteger     := Sid;
  SqlTemp.ParamByName('audsid').asInteger  := AudSid;
  SqlTemp.ParamByName('Terminal').asString := Terminal;
  SqlTemp.ParamByName('Program').asString  := Programa;
  SqlTemp.ParamByName('Ip').asString       := GetIpAddress; // chama a função para pegar o IP
  SqlTemp.ParamByName('Username').asString := Username;
  SqlTemp.ParamByName('Port').asInteger    := Porta;
  SqlTemp.ExecSql;
  SqlTemp.Close;
   FreeAndNil(SqlTemp);
end;

1.4) Antes de entrar no formulário(Form no caso do Delphi), chamar a procedure para gravar log na Tabela LOG_ACESSO

procedure TFrmSimulador.FormActivate(Sender: TObject);
begin
       Grava_Log_Acesso(7000);
end;

1.5) Execução do exemplo, que é bem simples.Temos uma tabela chamada Funcionarios e caso ocorra alguma atualização na mesma, teremos o envio de uma mensagem, via Procedure Oracle, de forma que no exemplo proposto uma mensagem na tela do usuário informando que houve uma atualização na base, e questionando o mesmo, quanto a desejar atualizar os dados em sua tela(client). O componente responsável por receber a mensagem é o SERVERSOCKET, no caso do Delphi. Este componente fica “escutando” em uma porta pré-estabelecida,no nosso caso a 7000, quando a procedure Oracle disparar, esse componente instalado e configurado no client, será responsável “por escutar a mensagem” e automaticamente disparará o aviso na tela do usuário. Veja as Figuras 3 e 4.

Form Delphi em tempo de programação

Figura 3.Form Delphi em tempo de programação, exibindo os componentes

aplicativo client delphi

Figura 4. Aplicativo client, Delphi, em tempo de execução

Para configurar o sockets no client Delphi, foi incluindo um componente SERVERSOCKET, localizado na palheta INTERNET da IDE e a porta de comunicação (PORT) configurada com o número 7000 (este número de porta pode ser escolhido em um conjunto, favor verificar documentação e literatura à respeito) e definido ACTIVE como true no componente citado.

OBS: Caso a versão disponível da IDE for a versão Delphi 2007, na paleta INTERNET não vem instalado o componente SERVERSOCKET, para instalá-lo, vá ao menu Component/Install Packages e procure o arquivo dclsockets100.bpl que no nosso caso encontra-se no caminho C:\Arquivos de programas\CodeGear\RAD Studio\5.0\bin.

Usamos um componente TClientDataSet e o nomeamos como cds_funcionarios para trazer dados da tabela FUNCIONARIOS:


procedure TfrmSimulador.ServerSocket1ClientRead(Sender: TObject;
  Socket: TCustomWinSocket);
var
s: ShortString;
begin
s:= trim(Socket.ReceiveText); //recebe a string vinda do ORACLE
 if (s='ATUALIZA_PAINEL') then
   begin
    If application.messagebox('Houve uma alteração na tabela de Funcionários, deseja trazer mudanças?','Aviso',mb_yesno + mb_iconquestion ) = id_yes then
     begin
     cds_funcionarios.Close;
     cds_funcionarios.Open;
     end;
  end;
 end;
end.

Quando um evento do tipo update acontece na tabela FUNCIONARIOS, uma trigger dispara automaticamente o envio da mensagem para o componente DELPHI SERVERSOCKET, do aplicativo client, receber a mensagem. Se a mensagem enviada for ATUALIZA_PAINEL, o client emite uma mensagem para o usuário perguntando se ele quer atualizar a tela com os novos dados. O envio da mensagem ao client é realizado por uma procedure, no caso escrita em PL/SQL, que enviará a mensagem via TCP/IP para as estação clients. A procedure verifica todos os IPs que estão cadastrados na Tabela LOG_ACESSO para poder enviar a mensagem. Esta procedure tem dois parâmetros, Evento que receberá a mensagem a ser enviada e PORTA que é o número da porta que o client deve escutar.

OBS: o principal.exe é o nome do executável client que foi gravado na tabela LOG_ACESSO


 CREATE OR REPLACE PROCEDURE POST_EVENT(EVENTO VARCHAR2, PORTA NUMBER)
IS
 r SYS_REFCURSOR;
 
BEGIN
   for r in
    (
   select /*+ PARALLEL (6) */ 
     B.IP,B.PORT
     FROM V$SESSION A
     JOIN LOG_ACESSO B
     ON A.SID=B.SID
     AND A.AUDSID=B.AUDSID
     AND A.TERMINAL=B.TERMINAL
     AND A.USERNAME=B.USERNAME
     AND A.PROGRAM=B.PROGRAM
     AND A.LOGON_TIME=B.LOGON_TIME
     WHERE B.PORT=PORTA
     AND UPPER(B.PROGRAM)=UPPER('oprincipal.exe')
     )
   loop
      tcp_scan.scan(r.IP,r.PORT,EVENTO);
   end loop;
END POST_EVENT;

Nesse momento iremos criar um PACKAGE que recebe o HOST /PORTA/Mensagem, depois abre uma conexão TCP/IP e envia a mensagem desejada.


CREATE OR REPLACE PACKAGE TCP_SCAN IS
PROCEDURE SCAN(HOST VARCHAR2, PORTA NUMBER, EVENTO VARCHAR2);
PROCEDURE CHECK_PORT(HOST VARCHAR2, PORTA NUMBER, EVENTO VARCHAR2);
END TCP_SCAN;
/
 
 
CREATE OR REPLACE PACKAGE BODY TCP_SCAN IS PROCEDURE SCAN(HOST VARCHAR2, PORTA NUMBER, EVENTO VARCHAR2)
AS
BEGIN
CHECK_PORT(HOST,PORTA,EVENTO);
EXCEPTION WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('Um erro ocorreu!!');
END SCAN;
 
PROCEDURE CHECK_PORT(HOST VARCHAR2, PORTA NUMBER, EVENTO VARCHAR2) AS
CN SYS.UTL_TCP.CONNECTION;
NETWORK_ERROR EXCEPTION;
PRAGMA EXCEPTION_INIT(NETWORK_ERROR,-29260);
ret_val PLS_INTEGER;
BEGIN
CN := UTL_TCP.OPEN_CONNECTION(HOST, PORTA);
ret_val := utl_tcp.write_line(CN, EVENTO);
utl_tcp.close_connection(CN);
EXCEPTION WHEN NETWORK_ERROR THEN
utl_tcp.close_connection(CN);
DBMS_OUTPUT.PUT_LINE('Porta TCP  ' || PORTA || ' em ' || HOST || ' não está aberta.');
WHEN OTHERS THEN
utl_tcp.close_connection(CN);
DBMS_OUTPUT.PUT_LINE('Outro Erro ocorreu.');
END CHECK_PORT;
END TCP_SCAN;
/

Agora realizamos algumas configurações de segurança que o SGBD exige, na versão 11G o SGBD Oracle possui uma camada de segurança (ACL-access control list) que é responsável por permitir ou não, que os usuários de banco de dados façam uso de recursos de rede externo ao servidor de banco de dados através de pacotes como o própri oUTL_MAIL, UTL_SMTP, UTL_HTTP e UTL_TCP, mas não iremos entrar em maiores detalhes sobre o ACL pelo fato de não ser o objetivo deste artigo.

Portanto, no Oracle 11g, para que seja possível a utilização destes recursos,será necessário a configuração de algumas políticas de acesso (ACL) como demonstrado abaixo:


C:\>sqlplus sys/******* as sysdba
 
SQL*Plus: Release 11.1.0.6.0 - Production on Seg Abr 5 08:56:38 2010
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
Conectado a:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
SYS@ORACLE11> begin
      dbms_network_acl_admin.create_acl (
        acl         => 'tcp.xml',
        description => 'Permite enviar mensagem',
        principal   => 'TEST',
        is_grant    => TRUE,
        privilege   => 'connect'
        );
        commit;
   end;
   /
 
Procedimento PL/SQL concluído com sucesso.
 
SYS@ORACLE11> begin
      dbms_network_acl_admin.add_privilege (
      acl       => 'tcp.xml',
      principal => 'TESTE',
      is_grant  => TRUE,
      privilege => 'resolve'
      );
      commit;
    end;
   /
 
Procedimento PL/SQL concluído com sucesso.
 
SYS@ORACLE11> begin
      dbms_network_acl_admin.assign_acl(
      acl  => 'tcp.xml',
      host => '10.*.*.*'
      );
      commit;
    end;
    /
 
Procedimento PL/SQL concluído com sucesso.

Após a execução dos procedimentos acima, o usuário TESTE terá os privilégios necessários para a execução dos procedimentos existentes no pacote UTL_TCP.

Em seguida iremos providenciar que a procedure e o pacote fiquem o tempo todo em memória para que possam ser usados com mais eficiência.


EXECUTE dbms_shared_pool.keep('POST_EVENT');
EXECUTE dbms_shared_pool.keep('TCP_SCAN');

Enfim criamos a Trigger e a mensagem que deverá ser enviada aoclient, quando de atualizações nos dados da tabela FUNCIONARIOS.


CREATE OR REPLACE TRIGGER ALERTA
AFTER UPDATE ON FUNCIONARIOS
FOR EACH ROW
BEGIN
POST_EVENT('ATUALIZA_PAINEL',7000);
END ALERTA;

Quando acontece um update na tabela FUNCIONARIOS, uma trigger dispara automaticamente o envio da mensagem para os clients, no exemplo em Delphi o componente SERVERSOCKET recebe a mensagem. Se a mensagem enviada for ATUALIZA_PAINEL, no client um aviso é disparado para o usuário perguntando se ele deseja atualizar a tela com os novos dados.

serversocket

Para ilustrar como esse método é independente da linguagem de programação utilizada noclient, abaixo produzimos um outro exemplo, dessa vez em JAVA, de um client capaz de processar a mensagem:


Exemplo de Client Java recebendo o Evento
 
package EVENTO;
//Importa pacotes para a criação de fluxos.
import java.io.*;
//Importa pacotes para a criação de sockets.
import java.net.*;
 
public class Netuno {
 
    private ServerSocket server;
    private Socket socket;
    private InputStream entrada;
    private BufferedReader read;
 
    /** Cria uma nova instânica de Netuno */
    public Netuno() {
        try {
            //Abre uma porta para escuta (LISTENING)
            server = new ServerSocket(606);
 
            //Imprime a Mensagem "Servidor aguardando conexao."
            System.out.println("Servidor aguardando conexao.");
 
            //Aguarda e cria a uma conexão
            socket = server.accept();
 
            //Cria um fluxo de entrada 
            entrada = socket.getInputStream();
            read = new BufferedReader(new InputStreamReader(entrada));
 
            //Imprime o que veio na entrada
            System.out.println(read.readLine());
 
            //Fecha o fluxo o socket e o serverSocket
            read.close();
            socket.close();
            server.close();
 
        //Caso ocorra alguma exeção na criação do fluxo.
        } catch (IOException ex) {
            //Imprimi o que aconteceu de erro
            ex.printStackTrace();
        }
    }
 
    public static void main(String[] args) {
        //Chama o método construtor na classe
        new Netuno();
    }
 

Conclusão

É possível preencher a lacuna da atualização de consultas concorrentes em um ambiente de clients acessando um SGBD de tecnologia atual, de forma simples e por um grande conjunto de Linguagens de programação, de forma a gerar vantagens competitivas, diminuindo o número de erros de processamento em razão da não atualização dos resultados de consulta em clients, assim como é viável a utilização de técnicas diferentes, do uso de “Timer”(Temporizador), com a possibilidade de explorar o melhor balanceamento dos recursos de informática em função dos requisitos de negocio.Também demonstramos que no desenvolvimento desse novo método é perfeitamente viável a independência de fornecedor, seja ele do SGBD, visto que a maioria dos SGBDs, não somente os abordados nesse artigo, possuem as características necessárias para implementação do que foi exposto, assim como das linguagens de programação, usamos exemplos com duas linguagens modernas, e dessa forma propomos a criação de um framework multi-plataforma para facilitar e padronizar esse tipo de recurso nas diversas plataformas e facilitar a sua implementação trazendo ganhos a diversas áreas onde haja possibilidade de ganhos com sua aplicação.

Referências

DATE, C. J. Introdução ao sistema de banco dedados. Rio de Janeiro: Campus, 1991.

HEUSER, Carlos Alberto. Projeto de banco dedados.Porto Alegre: Sagra Luzzatto, 1999.

GARRET, J. J. (2005) “Ajax: A New Approach to Web Applications”
http://www.adaptivepath.com/publications/essays/archives/000385.php, Feb. 2005.Acesso em: 25 jul. 2006.

KUROSE, J. F.(2006) “Computer Networking Lab Manual Package”, 3.Ed, PRENTICE HALL,2006.

KORTH, Henry F.; SILBERSCHATZ, Abraham.Sistemas de banco de dados.São Paulo: MakronBooks, 1995.

KROENKE, David M. Bando de dados: fundamentos, projeto e implementação.RiodeJaneiro: LTC, 1999.

O’Reilly, T. (2005) “What is the Web 2.0: design patterns and business models for thenext generation of software”
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html,Sep. 2005. Acesso em: 25 jul. 2006.

Links

http://www.oracle.com

http://www.embarcadero.com