Banco de Dados OO NeoDatis ODB versão 1.8 está disponível

46 respostas
Olivier

A nova versão do banco de dados OO para java está Disponível. http://odb.neodatis.org

Esta versão traz várias novas funcionalidades e muito mais performance.

  • Melhor ‘refactoring’ automático do banco de dados
  • 'Refactoring manual’via API e ODB Explorer
  • Indíves mais rápidos
  • melhora na ferramenta gráfica ODB Explorer
  • 4 Distribuções : full, light, ODB Explorer , runtime
  • Melhor Cache
  • Menor consumo de memoria
  • Operações básicas como insert, updates, select e delete mais rápidos

Com o intuito de aumentar a comunidade do NeoDatis ODB, foi criado um wiki com exemplos e sobretudo explicando como funciona o banco de dados.

Também está disponível o benchmark de performance PolePosition comparando a performance entre o NeoDatis ODB e o Db4O.

clique aqui para baixar o relatório diretamente http://sourceforge.net/project/showfiles.php?group_id=179124&package_id=255373

46 Respostas

Luiz-SP

Alguem ja usou um banco OO em producao, o que achou?

genildof

Uso o db4o em 02 projetos pequenos, estou satisfeito com os resultados. Mas ainda espero que no futuro queries complexas nesses bancos sejam feitas de modo menos trabalhoso.

Olivier

Olá genildof,

você pode dar exemplo dessas queries?

Luiz_Aguiar

conheço algumas pessoas que usam o DB4O e estão muito satisfeitas.

glaucioguerra

Eu uso o db4o desde a versão 5.4. Realmente a parte de queries complexas dão um pouco de trabalho, mas queries complexas no sql ansi também dão :-). Atualmente não estou mais trabalhando com ele, mas na época atendeu muito bem. A última versão 7.0 beta também está muito boa, principalmente a parte de desempenho.

http://www.theserverside.com/news/thread.tss?thread_id=47646

Um abraço!

andre_guitar7

Também gostaria de saber se vale a pena usar esse tipo de banco. Estou cansado de usar Hibernate. Alguém pode relatar vantagens e desvantages? Ficaria muito grato…

Obrigado

Olivier

André,

vou tentar citar alguns

Algumas Vantagens :

  • Simplicidade, simplicidade, simplicidade

  • não há necessidade de mapear seus objetos para o paradigma relacional. Assim, vc tb não tem limitações no seu modelo de objetos de negócio. Simples cria seus objetos de negócio e manda persistir. Isto traz muita produtividade pois vc se concentra na sua lógica de negócio.

  • Os relacionamentos são automáticos pois são definidos nos seus objetos

  • Refactoring : Alguns bancos OO possuem Refactoring automático. Ou seja, vc alterou uma classe persistente, o BD se ajusta sozinho. Obviamente, algumas situações não poderam ser tratadas automaticamente e haverá necessidade de refactoring manual

  • Apesar de não ser uma vantagem dos BD OO, mas muitos dos BDs OO funcionam em Modo embarcado(embedded) e/ou Client/Server. O modo local permite usar o BD junto com a sua aplicação sem a necessidade de instalação de servidor. Isso pode ser uma vantagem interessante quando é necessário distribuir uma aplicação Desktop ou até para uma aplicação Web onde vc não controla o ambiente de execução.

  • Em modo embedded, vc consegue uma performance superior e em geral um tamanho de biblioteca inferior a 500Kb. Se vc usa Hibernate para acessar um banco relacional no minimo vc tem 3Mo de jars. Com esses BD OO (como NeoDatis) o runtime é menor que 400K. As vezes faz a diferença.

Algumas desvantagens :

  • Fica dificil ter uma equipe que cuida do banco e outra do desenvolvimento pois o modelo do banco de dados acaba sendo o modelo de negócio.

  • Bancos relacionais que estão há mais tempo no mercado devem ser mais robustos e confiáveis.

O mais importante ao meu ver é Simplicidade e Produtividade. Qdo começa a trabalhar com um BD OO como NeoDatis ODB ou DB4O e que tem que voltar a usar Hibernate para acessar um banco relacional, vc fica triste :slight_smile: .

Já tive que migrar uma aplicação que eu tinha feito com NeoDatis ODB para Hibernate/Oracle. Muitas coisas são simples mas quando começa a ter que mapear relações 1-n e n-n, vc percebe a diferença.

bandrade

Pessoas, nunca usei banco OO mas tenho uma duvida…

Bem, suponha que eu tenha uma classe transação.

Transação{

Id (int)

Hora (datetime)

Valor (decimal 10,4)

}

No banco de dados relacional eu posso ter infinitas transações com o mesmo valor e hora, pois elas serão identificadas pelo ID.

Num banco OO, como isso funciona? Alguém tem que distribuir os Id´s (identity, sequence, etc…). O banco faz isso??

Valeu.

Olivier

Olá Bandrade,

No banco OO, vc não precisa usar chave para seus objetos. O próprio banco se encarrega de criar um OID (Object ID) para cada objeto.

Mas em alguns casos vc pode precisar identificar o objeto de maneira única e o seu objeto não tem chave natural (que é o caso que vc citou da transação). Neste caso, vc pode pedir ao banco o OID do(s) objeto(s).

Um caso comum para isso é numa consulta WEB onde vc mostraria todas as transações e onde o usuário poderia clicar em uma das transações para ver o seu detalhe ou alterar a mesma. Nesse caso, eu aconselho usar o OID do BD. No NeoDatis ODB vc tem um método ODB.getObjectId(Object o) que te retorna o OID do objecto no banco (uma vez que o mesmo já tinha sido persistido no BD).

Vc depois pode recuperar um objeto pelo OID a qualquer momento mesmo em outra transação usando ODB.getObjectFromId(OID oid).

Era isso sua dúvida?

bandrade

Exatamente… muito bacana isso então.

Como ele trata views? é possível criar StoredProcedures que retorne um dataset customizado?

Fazer relatório com esse paradigma não deve ser o mais produtivo no começo… ));

Olivier

Bandrade,

Sobre Views e Stored Procedure não sei responder para todos os BD OO, Eu sei NeoDatis ODB ainda não suporta e acho que Db4O também não. NeoDatis ODB suporta triggers.

Com relação a relatórios, vai depender da ferramenta. Se não me engano, se vc usa JasperReport, vc pode passar um Model que contém os objetos (não tenho certeza disso)

bandrade

Dei uma pesquisada nas páginas desses bancos, o NeoDatis não tem suporte oficial a .net ainda, o Db4O já tem…

Atualmente trabalho com .net (todos produtos MS), todos os relatorios q o pessoal do BI faz usa o Reports da MS mesmo…

Exemplo: Com a transação lá, vou fazer uma modificação na classe/tabela

class Transacao{

idTransacao

idCliente

Data

Valor

}

É possível fazer um somatório de todas as transações de um cliente em determinado periodo de maneira simples? No relacional isso é até sem graça de fazer. \o/

–Editado–
Como o banco trata esse retorno dessa função/procedure?? No relacional ele volta um datareader ou dataset e você se vira, no relaciona ele retorna um objeto?? Ele tem que carregar a coleção dessas transações para fazer a soma?

andre_guitar7
É possível usar generics? Ou tenho que ficar fazendo cast sempre quando vou recuperar um objeto?

É possível usar generics? Ou tenho que ficar fazendo cast sempre quando vou recuperar um objeto?

Olivier

Bandrade,

realmente BDOO não são muitos bons nesses tipos de query pois eles trabalham com objetos e a suma de um dos atributos acaba fugindo do conceito do objeto :frowning:

Mas vc tem razão isso é importante.

O NeoDatis ODB tem um recurso para isso : O Trigger AfterSelect.

vc pode registrar um trigger chamando o ODB.addSelectTrigger( ISelectTrigger trigger );

Esse trigger irá receber todos os objetos selecionados e ai vc faz o que quiser em Java, por exemplo soma o valor da Transação. No nosso exemplo o trigger seria assim:

public class SumTrigger implements ISelectTrigger {

	private double totalValue;
	
	public void afterSelect(Object object, OID oid) {
		Transaction t = (Transaction) object;
                // Soma o valor da transação ao valor total
		totalValue+=t.getValue();
	}

	public double getTotalValue() {
		return totalValue;
	}
}

Até testei para se funcionava e funcionou.

o código principal seria assim :

public void test1() throws Exception{
		ODB odb = null;
		
		try{
                        // abre o banco
			odb = open("trigger-sum.odb");
			double sum = 0;
			for(int i=0;i<1000;i++){
				// cria 1000 objetos de tipo Transaction
                                odb.store(new Transaction(10,i));
				sum+=i;
			}
                        // Fecha o banco
			odb.close();
			
                         // Abre o banco
			odb = open("trigger-sum.odb");

                        // Adiciona o Tigger AfterSelect no engine ODB
			odb.addSelectTrigger(new SumTrigger());

                        // executa a query 
			Objects objects = odb.getObjects(new CriteriaQuery(Transaction.class,Where.equal("clientId", 10L)));

                        // Mostra o valor calculado pelo trigger
			System.out.println("Valor total = " + trigger.getTotalValue()  +" - " + sum);
			assertEquals(String.valueOf(sum), String.valueOf(trigger.getTotalValue()));
			
		}finally{
			if(odb!=null){
				odb.close();
			}
		}
	}

Agora, vc tem razão, fazendo isso, o ODB acaba lendo todas as instâncias que atendem a query. Poderia ser otimizado para só ler o valor que está sendo somado. Provavelmente numa próxima versão terá uma otimização para isso :slight_smile:

Olivier

Andre,

por enquanto o NeoDatis ODB não tem versão específica para java 1.5. E ai não tem como usar Generics :-(. Mas está na lista de Feature Request!

Ferryman

Eai pessoal,

Muito interessante ver o desenvolvimento dos bancos de dados OO. Pretendo usar algum em um sistema pequeno somente como experiência… mas acredito que pra sistemas grandes os bancos OO ainda não atingiram um nivel de maturidade suficiente.
Espero que não demore muito para que esses bancos atinjam um nível de desempenho aceitável.

Uma coisa que não entendi é, tendo um banco de dados OO, a existência de procedures não acaba indo contra a idéia da OO? Hoje com as ferramentas O/R eu não utilizo nenhuma procedure nem triggers. O meu banco serve somente para armazenar dados.

O que vocês acham?

[]s
Ferry

bandrade

Depende da performance que você quer… no meu sistema atual eu coloco o máximo de coisas possíveis no Banco, precisamos do processamento.

Para mapeamento O/R uso o .netTiers (www.nettiers.com) e ele mapeia para mim as procedures tb, que acesso como se fosse uma função do DataProvider. Muito produtivo. (;

Trigger eu nunca gostei porque não é tão performático no banco, então não posso usar.

Olivier

Uma StoredProcedure num BDOO acaba sendo um método de uma classe Java/.Net que será executado no servidor remoto em vez do cliente.

Com relação a Trigger por exemplo, estamos usando Trigger do NeoDatis ODB para implementar uma base de dados MultiMedia onde vc grava um objeto de tipo MultiMediaFile e um trigger, de maneira transparente para vc, irá tratar o arquivo em background.

andre_guitar7

E como funciona o carregamento dos atributos do objeto? O Hibernate tem o lazy, por exemplo. Carrego um objeto e os subobjetos são carregagos somente quando invoco. Como funciona no NeoDatis?

Olivier

Oi Andre,

o NeoDatis ainda não tem esse mecanismo :frowning:

Mas vale a pena postar uma Feature Request no SourceForge…

andre_guitar7

Digamos que eu tenha um objeto e esse objeto tem um getOutroObjeto e assim vai e o meu objeto inicial tem outro getObjeto que tem vários outros objetos… ele vai carregar tudo isso de uma vez só?

Por exemplo: tenho um objeto Estado, que tem getCidades, que cada cidade tem getBairros, que cada bairro tem getLogradouros… imagine só

Olivier

Sim vc tem razão, vai carregar tudo!

Vc pode colocar uma Feature Request no http://sourceforge.net/tracker/?group_id=179124&atid=887888

Valeu Andre

andre_guitar7

Olivier:
Andre,

por enquanto o NeoDatis ODB não tem versão específica para java 1.5. E ai não tem como usar Generics :-(. Mas está na lista de Feature Request!

Se isso for feito, já estarão a frente do Hibernate.

andre_guitar7

Olivier:
Sim vc tem razão, vai carregar tudo!

Vc pode colocar uma Feature Request no http://sourceforge.net/tracker/?group_id=179124&atid=887888

Valeu Andre

Vou postar sim. Por padrão, acho eu, no Hibernate o OneToMany já vem com lazy=true, ou seja não carrega os objetos de um objeto já de cara. Não sei se tem como fazer isso da forma como o NeoDatis foi implementado, mas na minha opinião é algo que pode melhorar muito o desempenho do banco. Principalmente no exemplo que citei.

andre_guitar7

Olivier:
Sim vc tem razão, vai carregar tudo!

Vc pode colocar uma Feature Request no http://sourceforge.net/tracker/?group_id=179124&atid=887888

Valeu Andre

Acha que ele demora muito pra carregar todos os objetos que te falei? O Hibernate vai fazer um select de banco o NeoDatis carrega os objetos diretamente, certo?

Olivier

andre_guitar7:
Olivier:
Sim vc tem razão, vai carregar tudo!

Vc pode colocar uma Feature Request no http://sourceforge.net/tracker/?group_id=179124&atid=887888

Valeu Andre

Vou postar sim. Por padrão, acho eu, no Hibernate o OneToMany já vem com lazy=true, ou seja não carrega os objetos de um objeto já de cara. Não sei se tem como fazer isso da forma como o NeoDatis foi implementado, mas na minha opinião é algo que pode melhorar muito o desempenho do banco. Principalmente no exemplo que citei.

Com certeza deve melhorar. Na versão 1.5 tinhamos feito uma coisa parecida usando ASM mas tiramos pois estava aumentando bastante o tamanho do jar. Mas vamos analisar de novo. O único problema disso é que em vez de retornar uma instância da sua classe, retornaremos uma instância de uma classe criada em runtime (usando ASM) que herda da sua classe em quais os métodos get que retornam objetos não nativos farão o load on demand. Neste caso, se alguem compara a classe usando == não funcionará. Mas Hibernate faz a mesma coisa, ele retorna uma subclasse da sua com o nome NomeClasse_enhancedByCGlib usando CGLib, então não deve ser tão problemático.

Olivier

andre_guitar7:
Olivier:
Sim vc tem razão, vai carregar tudo!

Vc pode colocar uma Feature Request no http://sourceforge.net/tracker/?group_id=179124&atid=887888

Valeu Andre

Acha que ele demora muito pra carregar todos os objetos que te falei? O Hibernate vai fazer um select de banco o NeoDatis carrega os objetos diretamente, certo?

Andre, não sei se entendi bem a pergunta…

genildof
Olivier, sou iniciante no uso desses bancos, estou até pesquisando o Neodatis. Por exemplo, no db4o, tive problemas com SODA queries e Enums (Ver. 6.4), então tive que partir para Native Queries, para realizar uma consulta de OSs, não encerradas, de determinado período, ordenadas por data:
public void listaBasDeHoje() {
		ba_lista = ba_dao.getSession().query(new Predicate&lt;BA&gt;() {
			private static final long serialVersionUID = 1L;

			public boolean match(BA ba) {
				return (ba.getStatus() != BA_Status.Finalizado
						&& ba.getData_promessa().after(data_inicial) && ba
						.getData_promessa().before(data_final));
			}
		}, new Comparator&lt;BA&gt;() {
			public int compare(BA ba1, BA ba2) {
				return ba1.getData_promessa().compareTo(
						ba2.getData_promessa());
			}

		});
	}
Fiquei pensando se tivesse de fazer agrupamentos ou algo do gênero, como ficaria. Poderia dar alguma dica ou exemplo com o Neodatis. A propósito, o Neodatis tem integridade referencial?

Grato,

Olivier

Genildof,

O NeoDatis não suporta group by de maneira nativa. Mas o NeoDatis tem um recurso que permite tratar isso : Os triggers. Vc pode criar um trigger afterSelect que será chamado para cada objeto onde vc poderá fazer o que for preciso como agrupar ou somar seus dados.

Dê uma olhada no thread http://www.guj.com.br/posts/list/76970.java na última resposta (minha) da primeira página onde eu mostro como fazer um sum.

Me fale se ajuda, ok?

Com relação aos enum, não sei, eu vou testar.

Esqueci: NeoDatis ainda não suporta Integridade referencial. Mas está no RoadMap.

andre_guitar7

Olivier:
andre_guitar7:
Olivier:
Sim vc tem razão, vai carregar tudo!

Vc pode colocar uma Feature Request no http://sourceforge.net/tracker/?group_id=179124&atid=887888

Valeu Andre

Vou postar sim. Por padrão, acho eu, no Hibernate o OneToMany já vem com lazy=true, ou seja não carrega os objetos de um objeto já de cara. Não sei se tem como fazer isso da forma como o NeoDatis foi implementado, mas na minha opinião é algo que pode melhorar muito o desempenho do banco. Principalmente no exemplo que citei.

Com certeza deve melhorar. Na versão 1.5 tinhamos feito uma coisa parecida usando ASM mas tiramos pois estava aumentando bastante o tamanho do jar. Mas vamos analisar de novo. O único problema disso é que em vez de retornar uma instância da sua classe, retornaremos uma instância de uma classe criada em runtime (usando ASM) que herda da sua classe em quais os métodos get que retornam objetos não nativos farão o load on demand. Neste caso, se alguem compara a classe usando == não funcionará. Mas Hibernate faz a mesma coisa, ele retorna uma subclasse da sua com o nome NomeClasse_enhancedByCGlib usando CGLib, então não deve ser tão problemático.

Poisé, é complicado na hora do debug. O Hibernate retorna uns objetos estranhos, diferentes dos que eu persisti, deve ser justamente por causa do CGLib. O ideal é o que o NeoDatis faz hoje: retorna o objeto que eu persisti, do jeito que estava. Não fiz nenhum teste com ele ainda, talvez o exemplo do Estado, Cidade, Bairros e logradouros como citei não seja muito demorado. Preciso testar.

Olivier

Oi André,

Para permitir esse lazy load, pelo que eu saiba não tem jeito vai ter que ser criando um subclasse da sua própria classe em tempo de runtime.

O Db4O tem o conceito de Activation onde vc pode definir a profundidade até qual vc quer carregar seus objetos. e ai não precisa gerar outra classe. Mas não fica tão ‘transparante’. Pq depois vc tem que ativar na mão os objetos.

O que vc acha?

andre_guitar7

Olivier:
Oi André,

Para permitir esse lazy load, pelo que eu saiba não tem jeito vai ter que ser criando um subclasse da sua própria classe em tempo de runtime.

O Db4O tem o conceito de Activation onde vc pode definir a profundidade até qual vc quer carregar seus objetos. e ai não precisa gerar outra classe. Mas não fica tão ‘transparante’. Pq depois vc tem que ativar na mão os objetos.

O que vc acha?

Porque não ficaria tão transparente? Como funciona exatamente o Activation do DB40?

andre_guitar7

Olivier:
Oi André,

Para permitir esse lazy load, pelo que eu saiba não tem jeito vai ter que ser criando um subclasse da sua própria classe em tempo de runtime.

O Db4O tem o conceito de Activation onde vc pode definir a profundidade até qual vc quer carregar seus objetos. e ai não precisa gerar outra classe. Mas não fica tão ‘transparante’. Pq depois vc tem que ativar na mão os objetos.

O que vc acha?

Dei uma olhada no Activation. Relamente, tenho que ativar na mão quando chego no nível limite definido. Não tem como o NeoDatis detectar quando chega nesse nível? O Hibernate detecta e popula o objeto.

Olivier

André,

o conceito de Activation do Db4O até a versão 6 funciona assim. Vc pode dizer para o Db4O até qual profundidade vc quer carregar o grafo de objetos.
Por exemplo, no seu exemplo de Estada, se vc coloca activation depth igual a 1, Os objetos de tipo Estado serão carregados mas as cidades não, o getCidades retornará nulo. Mas vc ainda pode manualmente ativar as cidades. Por isso que falo que não é tão transparente, pq vc tem que fazer na mão. Na versão 7 do Db4o, eles já tem o que eles chamam de TransparentActivation, que é o que chamamos de lazy loading. E acho que fica melhor pq que o engine não carrega os objetos, mas qdo vc acessa um atributo (que não foi carregado) ele carrega na hora pelo seu OID.

Olivier

Se tem como detectar e fazer o load automaticamente. Mas isso só usando byte para te retornar uma subclasse da sua classe onde os getters serão redefinidos da seguinte forma:

Classe original

public class Estado{
   private Collection cidades;

   public Collection getCidades(){
      return cidades;
   }
}

Classe gerada por byte code instrumention no runtime:

public class Estado_NeoDatis extends Estado{

   private OID cidadesOid;

   public Collection getCidades(){
      if(cidades==null){
         cidades = loadOnDemand(cidadesOid);
      }
      return super.getCidades();
   }
    
}

Ou seja, o NeoDatis estará retornando instâncias de Estado_NeoDatis em vez de Estado para ter o controle dos getters e fazer o lazy load.

andre_guitar7

Olivier:
André,

o conceito de Activation do Db4O até a versão 6 funciona assim. Vc pode dizer para o Db4O até qual profundidade vc quer carregar o grafo de objetos.
Por exemplo, no seu exemplo de Estada, se vc coloca activation depth igual a 1, Os objetos de tipo Estado serão carregados mas as cidades não, o getCidades retornará nulo. Mas vc ainda pode manualmente ativar as cidades. Por isso que falo que não é tão transparente, pq vc tem que fazer na mão. Na versão 7 do Db4o, eles já tem o que eles chamam de TransparentActivation, que é o que chamamos de lazy loading. E acho que fica melhor pq que o engine não carrega os objetos, mas qdo vc acessa um atributo (que não foi carregado) ele carrega na hora pelo seu OID.

É justamente isso. O interessante é a transparência. Se o NeoDatis não depender do programador pra popular os subobjetos, seria interessante. Vou tentar baixar aqui na minha empresa e testar, to curioso pra ver como funciona.

Olivier

Se vc quiser entender como funciona tb pode acessar http://neodatis-odb.wikidot.com/how-odb-works

Qualquer dúvida pode postar no source forge!

Valeu Andre!

andre_guitar7

Olivier:
Se tem como detectar e fazer o load automaticamente. Mas isso só usando byte para te retornar uma subclasse da sua classe onde os getters serão redefinidos da seguinte forma:

Classe original

public class Estado{
   private Collection cidades;

   public Collection getCidades(){
      return cidades;
   }
}

Classe gerada por byte code instrumention no runtime:

public class Estado_NeoDatis extends Estado{

   private OID cidadesOid;

   public Collection getCidades(){
      if(cidades==null){
         cidades = loadOnDemand(cidadesOid);
      }
      return super.getCidades();
   }
    
}

Ou seja, o NeoDatis estará retornando instâncias de Estado_NeoDatis em vez de Estado para ter o controle dos getters e fazer o lazy load.

Dessa forma somente seria invocado o subobjeto quando chamado mesmo, certo? Mas pra isso, o programador teria que implementar uma classe filha Estado_NeoDatis, né?

Olivier

Sim

Não, o NeoDatis fará isso automaticamente no runtime usando Byte Code instrumentation.

andre_guitar7

Olivier:

Dessa forma somente seria invocado o subobjeto quando chamado mesmo, certo?

Sim

Não, o NeoDatis fará isso automaticamente no runtime usando Byte Code instrumentation.

Olivier, aguardo ancioso a implementação dessa funcionalidade então. Boa sorte!

André

andre_guitar7

Mais uma perguntinha: como funciona a concorrência do arquivo do banco? Se eu tenho várias instâncias da web, por exemplo, todas estas instâncias podem acessar este mesmo arquivo aberto?

Olivier

André,

Em modo local, varios usuários não poderão acessar o mesmo bd.

vc tem duas opções para aplicações WEB:

  1. Configura ODB em modo local para ser usado em multithread usando Configuration.useMultiThread(boolean yes, int numberOfThreads). Neste caso, ODB, ao detectar um lock no arquivo do bd, irá esperar um pouco e tentar de novo, isso várias vezes (o número de vezes depende do número de threads)
    Como em geral as operações de persistência são rápidas, alguns ms, essa opção resolve.

  2. Use em modo Cliente/Servidor

andre_guitar7

Olivier:
André,

Em modo local, varios usuários não poderão acessar o mesmo bd.

vc tem duas opções para aplicações WEB:

  1. Configura ODB em modo local para ser usado em multithread usando Configuration.useMultiThread(boolean yes, int numberOfThreads). Neste caso, ODB, ao detectar um lock no arquivo do bd, irá esperar um pouco e tentar de novo, isso várias vezes (o número de vezes depende do número de threads)
    Como em geral as operações de persistência são rápidas, alguns ms, essa opção resolve.

  2. Use em modo Cliente/Servidor

Desculpe, não entendi direito: o número de threads é o número de usuários simultâneos? Como posso deixar em modo Cliente/Servidor e qual é a vantagem de deixar nesse modo?

Olivier

Sim seria isso.

vc tem que iniciar um Servidor (Pode ser no init de uma das suas servlet por exemplo ou até fora do seu application server).
Nesse exemplo, inicia na porta 10000

public class Server {
	public static void main(String[] args) throws Exception {
		ODBServer server = ODBFactory.openServer(10000);
		server.setAutomaticallyCreateDatabase(true);
		server.startServer(true);
	}
}

E o cliente, em vez de

use

Algumas vantagens:

  • Acesso concorrente
  • Acesso remoto

Desvantagens:

  • O modo local é muito mais rápido.
andre_guitar7

Sim seria isso.

Bom, é difícil prever quantos usuários em média acessarão o site da web. Por curiosidade, não tem como o NeoDatis gerenciar isso?

Olivier

Na realidade, você pode colocar um número pequeno pois estamos falando em conexões que irão abrir o banco de dados no mesmo milisegundo. Com 10 já está ok.

O NeoDatis não tem como saber isso. Mas poderia um valor default, concordo (Mais uma feature request?) .

Criado 11 de dezembro de 2007
Ultima resposta 14 de dez. de 2007
Respostas 46
Participantes 8