Restringir o acesso postges de clientes java usando o programa java no servidor

votos
1

Talvez esta pergunta não é muito clara, mas eu não encontrar melhores palavras para o título, que descreve o problema que eu gostaria de lidar com em breve.

Eu quero restringir o acesso a partir de um aplicativo de desktop java para postgres.

O fundo:

Suponha que você tenha 2 aplicativos em execução e a primeira aplicação tem que fazer alguns cálculos complexos com base em dados no db. Para pregar a imutabilidade dos dados no db para baixo eu gostaria de bloquear o db para inserir, atualizar e excluir operações. No lado do cliente i acha que é impossível para lidar com esse comportamento satisfatório. Então eu pensei em usar um pouco de java-aplicativo no lado do servidor que funciona como um proxy. Assim, a tarefa é entregar CRUD (Criar Apagar Leia Update) operações até que ele recebe um comando para bloquear. Depois de um bloqueio que rejeita todas as operações CUD até que ele recebe um comando de desbloqueio do cliente bloqueio ou um tempo limite é atingido.

Questões:

O que você acha sobre essa abordagem?

É possível bloquear um banco de dados durante a utilização de uma abordagem deste tipo?

Você prefere Java SE ou Java EE como aplicativo java do lado do servidor?

Desde já, obrigado.

Publicado 23/10/2008 em 17:42
fonte usuário
Em outras línguas...                            


3 respostas

votos
3

Por que não usar transações em suas operações? O banco de dados tem recursos para se manter a integridade dos dados, em vez de recorrer a uma operação bruta, como um bloqueio banco de dados total.

Este mecanismo de bloqueio você descreve soa como ele seria uma dor para os usuários. São os usuários initating o bloqueio ou é o próprio software? Se é os usuários, você pode esperar alguns problemas quando Bob bate bloqueio e, em seguida, vai para o almoço para 2 horas, esquecendo-se para desbloquear o banco de dados em primeiro lugar ...

Respondeu 23/10/2008 em 17:50
fonte usuário

votos
1

Na verdade ... há algumas formas adequadas para lidar com este problema.

  1. Apenas travar as tabelas em seu código. PostgreSQL tem comandos para travar tabelas inteiras em que você pode executar a partir de seu aplicativo cliente
  2. Escolha um nível de isolamento de transação que não têm o problema de leitura de dados que foi cometido após a sua txn iniciado (BEGIN TRANSACTION ISOLATION LEVEL LEIA repetível).

Destes, de longe, o mais eficiente é usar leitura repetida como seu nível de isolamento. Postgres suporta esta forma bastante eficiente, e ele vai te dar uma visão consistente dos dados sem tal bloqueio pesado do db.

Respondeu 23/10/2008 em 20:26
fonte usuário

votos
0

Ano eu pensei sobre as transações, mas neste caso eu não posso usá-los. Me desculpe eu não mencioná-lo exatamente. Assim, assumir o caso fácil seguir: Um cálculo fecha uma área de responsabilidade. Depois calc um novo é aberto e novas pastilhas são dedicados a ele. Mas, enquanto processo de cálculo a inserção ou atualização ou excluir não é permitido aos dados da área (atualmente calculado) de responsabilidade. Mais sobre uma exclusão é estritamente proibida porque os dados tem de ser arquivado.

Então imo o uso de operações não cabe a esse requisito. Ou será que eu perca algo.?

ps: @jsight (off topic): i atualmente ler que postgres intenally mApps "leitura repetida" para "serializável", portanto, usando "leitura repetida" você recebe mais restrição, então você talvez esperar.

Respondeu 24/10/2008 em 09:59
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more