Porto: Cidade Linux, Cidade Tecnológica

e cá está a prova de que estive lá…

Partilhar

Para além da hipótese que eu favorecia na altura (”por omissão”) foi também sugerida aquela que uso agora com mais frequência: “por pré-definição”. Diz a Priberam que é esta a melhor opção de tradução.

Recentemente, enquanto ajudava na tradução do Drizzle para português (se quiserem contribuir, é só dar um saltinho até aqui), surgiu-me uma dúvida relacionada. Como traduzir a expressão “non-default”? Aqui fica a frase em que a encontrei:

 Non-default option to alias SYSDATE() to NOW() to make it safe-replicable.

Parece-me claro que não se pode usar nenhuma variante do “pré-definido” neste contexto, simplesmente não funciona. O significado dado à palavra “default”, neste caso específico, parece ser mais próximo de “standard” (uma vez que efectivamente se está a falar de uma opção que sai fora do standard SQL), pelo que faria mais sentido optar por “padrão” ou “norma” que são provavelmente as traduções mais comuns.

Seja como for não consigo encontrar uma tradução que me deixe satisfeito, excepto talvez a opção de traduzir só parcialmente e dizer “Opção não default (…)”.

O que fariam vocês?

Partilhar

A primeira opção é a escolha típica numa aplicação stand-alone, mas a opção de utilizar uma datasource JNDI é a que faz mais sentido para application servers. Portanto, o ficheiro de configuração do Hibernate há-de ter, parcialmente, este aspecto:

<hibernate-configuration>
<session-factory>
<property name="hibernate.connection.datasource">
java:my_app_name
</property>
<property name="hibernate.setup">true</property>
<property name="hibernate.dialect">
org.hibernate.dialect.MySQLInnoDBDialect
</property>
<property name="transaction.factory_class">
org.hibernate.transaction.JDBCTransactionFactory
</property>
<property name="current_session_context_class">
thread
</property>
</session-factory>
</hibernate-configuration>

Depois basta definir a datasource com o nome JNDI correspondente, por exemplo assim:

<datasources>
<local-tx-datasource>
<jndi-name>my_app_name</jndi-name>
<connection-url>jdbc:mysql://host_or_ip/db_name</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>username</user-name>
<password>password</password>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</local-tx-datasource>
</datasources>

Agora que está tudo montado como manda a documentação, sugiro uma experiência:

1. Ligar servidor BD.
2. Ligar application server.
3. Testar aplicação que se liga à base de dados (funciona)
4. Reiniciar servidor BD (ou esperar 8 horas).
5. Testar aplicação que se liga à base de dados (não funciona!)

Então… tanto trabalho para abstrair a ligação a base de dados e um simples restart da base de dados deixa as ligações geridas pelo Hibernate todas inválidas? E, pior, não há recuperação automática?

Pois… parece que não. E acrescentar o parâmetro autoReconnect=true ao URL JDBC também não resolve, aliás, a utilização desse parâmetro até é desaconselhada, como se pode ver pelo que diz no manual:

Should the driver try to re-establish stale and/or dead connections? If enabled the driver will throw an exception for a queries issued on a stale or dead connection, which belong to the current transaction, but will attempt reconnect before the next query issued on the connection in a new transaction. The use of this feature is not recommended, because it has side effects related to session state and data consistency when applications don’t handle SQLExceptions properly, and is only designed to be used when you are unable to configure your application to handle SQLExceptions resulting from dead and stale connections properly. — MySQL 5.0 Reference Manual

A solução que encontrei para MySQL (e que também funciona para MS SQL Server), é acrescentar a seguinte linha ao ficheiro de configuração da datasource:

<check-valid-connection-sql>SELECT 1</check-valid-connection-sql>

Esta opção faz mesmo aquilo que parece fazer, ou seja, antes de usar uma ligação, a query ali especificada é executada como forma de verificar se a ligação é usável. Se não ocorrer nenhum erro, a instrução SQL que realmente se pretende executar é enviada pela mesma ligação, se houver um erro, a ligação é descartada e é criada uma nova.

Claro que isto tem um impacto sério na performance uma vez que se está a duplicar o número de queries, o que pode ser particularmente grave se o acesso à base de dados for feito através de um canal de elevada latência (rede, por exemplo).

Aparentemente existem soluções melhores para outras bases de dados, como o seguinte comentário parece sugerir:

Whilst you can use the old “select 1 from dual” trick, the downside with this is that it issues an extra query each and every time you borrow a connection from the pool. For high volumes, this is wasteful.

JBoss provides a special connection validator which should be used for Oracle:

org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker

This makes use of the proprietary ping() method on the Oracle JDBC Connection class, and uses the driver’s underlying networking code to determine if the connection is still alive. — stackoverflow.com

Alguém conhece uma alternativa semelhante para MySQL?

Partilhar

Partilhar

Uma das novidades é o novo sistema de actualizações de plugins e features, o P2. Vale a pena ler este artigo, sobretudo para quem desenvolve plugins para o dito.

Partilhar

Pretendia usá-lo como router/access point convencional, mas também como:

• print server - para uma HP com interface USB;
• file server - usando como dispositivo de armazenamento uma pen ou disco usb externo;
• ipsec gateway - para estabelecer uma VPN com a firewall corporativa e permitir acesso aos PCs lá de casa;

Tudo isto podia ser conseguido com o firmware original do router, excepto a parte do ipsec. Como também tinha alguma curiosidade em instalar Linux em sistemas “embedded”, resolvi  experimentar.

A primeira tentativa foi com o DD-WRT, mas não gostei do sistema de ficheiros read-only, nem do feel da coisa. A segunda tentativa foi com o OpenWRT, e desta vez fiquei satisfeito. A documentação existente no wiki é francamente boa, tanto no que diz respeito aos procedimentos de instalação, como também à configuração e afinação final.

Consegui completar todos os objectivos traçados recorrendo à documentação existente no wiki, com excepção de um pequeno pormenor. Depois de estabelecida a VPN com a firewall corporativa, dá muito jeito que as queries DNS para o domínio interno da rede corporativa sejam enviadas através da VPN até aos servidores responsáveis pela zona. O DNSMasq tal como vem instalado só permite encaminhar todas as queries para um (ou mais servidores), ou resolvê-las a partir dos root servers. Parecia não haver forma de fazer um encaminhamento selectivo de queries de certos domínios para um (ou mais servidores) de DNS.

Acabei por descobrir a solução na manpage do DNSMasq. Há um switch que permite definir exactamente isso:

-S /private.domain/w.x.y.z

Acrescentando este switch à variável args do script de arranque em /etc/init.d/dnsmasq consegue-se que o router encaminhe todas as queries de DNS para a zona private.domain para o servidor de DNS com o endereço w.x.y.z.

Partilhar

CREATE TABLE newtable LIKE mytable;

Pensei que devia existir algo equivalente para copiar as definições de uma base de dados inteira, mas aparentemente não existe.
A forma mais fácil de conseguir o mesmo resultado é provavelmente usar o mysqldump com a seguinte opção:

--no-data

No entanto, já há bastante tempo que queria experimentar os stored procedures do MySQL, por isso aproveitei a oportunidade para escrever o meu primeiro:

delimiter //
DROP PROCEDURE IF EXISTS copySchema //
CREATE PROCEDURE copySchema(IN schemaname CHAR(64))
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE table_a CHAR(64) default 'testing';
DECLARE cur1 CURSOR FOR SELECT TABLE_NAME FROM information_schema.tables WHERE TABLE_SCHEMA = schemaname;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN cur1;
REPEAT
FETCH cur1 INTO table_a;
IF NOT done THEN
SELECT CONCAT('CREATE TABLE ', table_a, ' LIKE ', schemaname, '.', table_a) into @sqlstr;
PREPARE stmt FROM @sqlstr;
EXECUTE stmt;
END IF;
UNTIL done END REPEAT;
CLOSE cur1;
END
//
delimiter ;

CALL mydb.copySchema('mysql');

Referências:

• Create Procedure
• Cursors
• Prepared Statements

Partilhar

Em Windows, o JBoss Portal instala-se como um serviço, recorrendo para isso a um script chamado:

installJBoss402.bat

Nesse script, a linha que efectivamente regista o serviço no Windows é a seguinte:

JBossPortal262Service.exe -install %SERVICE_NAME% %JDK_HOME%\jre\bin\server\jvm.dll -Djava.class.path=%JBOSS_HOME%\run.jar;%JDK_HOME%\lib\tools.jar -Dlocal.copy=false -Xms256m -Xmx512m -XX:MaxPermSize=128m run.jar -start org.jboss.Main -stop org.jboss.Main -method systemExit -out %LOGS_HOME%\stdout.log -err %LOGS_HOME%\stderr.log -current %JBOSS_HOME% -manual

Para conseguir trocar o default bind address é preciso passar a mesma propriedade que referi no artigo anterior à classe que arranca o JBoss. Isso pode ser feito modificando a linha anterior da seguinte forma:

JBossPortal262Service.exe -install %SERVICE_NAME% %JDK_HOME%\jre\bin\server\jvm.dll -Djava.class.path=%JBOSS_HOME%\run.jar;%JDK_HOME%\lib\tools.jar -Dlocal.copy=false -Xms256m -Xmx512m -XX:MaxPermSize=128m run.jar -start org.jboss.Main -params -Djboss.bind.address=<ip_address> -stop org.jboss.Main -method systemExit -out %LOGS_HOME%\stdout.log -err %LOGS_HOME%\stderr.log -current %JBOSS_HOME% -manual

A posição do parâmetro adicional é relevante! Deve aparecer imediatamente a seguir ao valor da opção -start.

A título de curiosidade, podem encontrar aqui uma lista de todos os parâmetros que controlam o funcionamento do JavaService.

Os créditos vão todos para o Manuel Costa que não desistiu enquanto não descobriu a solução correcta.

Partilhar

 Os conectores são definidos em:

JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml

e usam todos a variável:

${jboss.bind.address}

Há vários documentos (como por exemplo este) que sugerem substituir a variável directamente pelo IP pretendido. No entanto, esta variável é utilizada em muitos outros sítios (por exemplo pelo RMI e JNDI) e seria bem mais simples e limpo alterar a variável no arranque do servidor.

A primeira coisa que me ocorreu foi modificar o script de arranque:

JBOSS_HOME/bin/run.sh

acrescentando a seguinte linha:

JAVA_OPTS=”$JAVA_OPTS -Djboss.bind.address=`hostname`”

Mas não funcionou. A variável continuava a vir inicializada com o valor “localhost”.

Ao fim de muito procurar descobri esta resposta a um post. A única diferença entre o sugerido e aquilo que fiz, é que a definição da variável é passada como argumento ao script de arranque (que por sua vez a passa para o comando que é executado), em vez de ser definida em JAVA_OPTS e passada directamente à JVM.

Não percebo inteiramente porque é que isto funciona, por isso se alguém me souber explicar, agradeço!

Curiosidade: há um documento no wiki do JBoss Portal que sugere e explicar como usar iptables para publicar o JBoss Portal!

Partilhar

A dynamic proxy class is a class that implements a list of interfaces specified at runtime such that a method invocation through one of the interfaces on an instance of the class will be encoded and dispatched to another object through a uniform interface. [Sun]

A ideia já tem o seu tempo e como seria de esperar existe um pattern na raíz de tudo isto:

The Proxy pattern involves the creation of a “stub” or “surrogate” object, whose purpose is to accept requests and forward them to another object that actually does the work. [IBM]

E para que é que isto serve? Isolamento pode ser uma razão, mas há outras utilizações possíveis, seja para criar versões traceable de classes existentes, ou para introduzir strong typing em tipos de dados abstractos, ou para certos containers implementarem EJBs.

Bom proveito!

Partilhar