Миграция данных между БД

Перемещение/преобразование данных между разными БД требует использование хорошо отлаженного механизма выполнения sql-запросов, которые необходимы для импорта/экспорта данных между БД. Написание такого рода движка потребует не мало времени и усилий.

Среди open-source решений на java мне известны два инструмента решающих подобную задачу - JDBCImporter и Scriptella. Первый инструмент делает экспорт данных сначала в xml, а затем производит из него импорт, т.е. имеет промежуточный xml при обработке данных. Сам JDBCImporter имеет утечки памяти при обработки данных больших объемов, да и как-то не активно развивается.

Scriptella - это инструмент для выполнения ETL (Extract-Transform-Load) процесса, который позволяет собирать данные из одного или нескольких источников данных и загружать их в другие позволяя выполнять различного рода трасформацию самих данных. При трансформации данных можно использовать скрипты прямо в sql-запросах, написанных на Velocity, JavaScript, JEXL... Сама конфигурация etl-процесса описывается в xml файле:

<!DOCTYPE etl SYSTEM "http://scriptella.javaforge.com/dtd/etl.dtd">
<etl>
    <description></description>
    <properties>
        <include href="script.properties"/>
        driver=org.jdcDriver
    </properties>
    <connection id="con1" driver="$driver" url="${url}" user="$user" password="12345678">
        driver.property=value
    </connection>
    <connection id="con2" url="jdbc:hsqldb:file:db" user="sa" password=""/>
    <script connection-id="out">
     <include href="dbschema.sql"/>
    </script>
    <query connection-id="in">
        SELECT * from Bug
        <script connection-id="out">
            INSERT INTO Bug VALUES (?ID, ?priority, ?summary, ?status);
        </script>
    </query>
</etl>

В описании конфигурации выделяют три основных элемента:

• connection - представляет собой соединение с источником данных, таковым может являться как БД, XLS, CSV, XML... Можно также реализовать свой драйвер источника данных для Scriptella.

• script - скрипт, написанный на языке источника данных к которому он относится через connection-id. Именно здесь выполняются различные скрипты на Velocity, JavaScript, JEXL и т.д.

• query - запрос, выполняемый на источнике данных connection-id. Может содержать любое кол-во вложенных query и script элементов.

Запуск Scriptella можно произвести из командной строки, с помощью Ant-а, либо прямиком из Java.

Event-Driven Development в Spring. Часть 2

Механизм рассылки event-ов в контексте Spring реализован одним интерфейсом org.springframework.context.event.ApplicationEventMulticaster. Именно ему и будут делегироваться все добавления, удаления listener-ов, а также публикация event-ов для них. По-умолчанию, в качестве реализации такого интерфейса будет использоваться объект класса org.springframework.context.event.SimpleApplicationEventMulticaster. В самом же контексте данный bean регистрируется под именем applicationEventMulticaster. Однако, если под таким именем bean уже существует и реализует нужный интерфейс, то будет использоваться именно он.

Необоходимость создания своего ApplicationEventMulticaster-а может возникнуть, например, чтобы рассылать event-ы по spring-контекстам целого кластера. Именно этот случай и реализован в моем примере. Сам механизм коммуникации между нодами обеспечивается фреймворком JGroups, который рассылает сообщения по сети multicast-ом через UDP-протокол. Объект com.blogspot.nkoksharov.springevents.jgroups.JGroupsMulticaster переопределяет метод void multicastEvent(ApplicationEvent event) и рассылает по сети лишь те экземпляры event-ов, классы которых являются подклассами com.blogspot.nkoksharov.springevents.jgroups.JGroupsEvent. А вот и сам код JGroupsMulticaster-а:

package com.blogspot.nkoksharov.springevents.jgroups;

import org.jgroups.*;
import org.slf4j.*;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.context.ApplicationEvent;
import org.springframework.context.event.SimpleApplicationEventMulticaster;

/**
 * Alternative multicaster to org.springframework.context.event.SimpleApplicationEventMulticaster
 *
 * @author nkoksharov
 *
 */
public class JGroupsMulticaster extends SimpleApplicationEventMulticaster    implements InitializingBean, DisposableBean, LocalEventMulticaster {

   private final Logger logger = LoggerFactory.getLogger(getClass());
   private JChannel jchannel;
   private JGroupsReceiver receiver = new JGroupsReceiver();
   private String configFile;
   private String clusterName;

   public void multicastEvent(ApplicationEvent event) {
      if (event instanceof JGroupsEvent) {
          try {
             jchannel.send(new Message(null, null, event));
          } catch (ChannelNotConnectedException e) {
             logger.error("channel not connected", e);
          } catch (ChannelClosedException e) {
             logger.error("channel closed", e);
          }
      } else {
          super.multicastEvent(event);
      }
   }

   public void localMulticastEvent(JGroupsEvent event) {
      super.multicastEvent(event);
   }

   public void afterPropertiesSet() throws Exception {
      jchannel = new JChannel(configFile);
      receiver.setLocalMulticater(this);
      jchannel.setReceiver(receiver);
      jchannel.connect(clusterName);
   }

   public void destroy() throws Exception {
      jchannel.close();
   }
   public void setConfigFile(String configFile) {
      this.configFile = configFile;
   }
   public void setClusterName(String clusterName) {
      this.clusterName = clusterName;
   }
}

Рассылка же абсолютно всех event-ов, в частности системных, может привести к некорректной работе всего spring-контекста.

Проект собирается с помощью Maven-а и запускается командой:

mvn compile exec:java

Каждый запуск - это новый контекст, т.е. можно запустить приложение на разных компьютерах в локальной сети и наблюдать появление сообщений в консоли о получении event-ов. Также можно запустить несколько экземпляров приложения на одном компьютере, все должно работать.

Скачать исходники
Event-Driven Development в Spring. Часть 1

Rhino и Janino для вычисления математических выражений

Для вычисления математических формул в run-time можно воспользоваться script-движком реализующим JSR-223. В Java 1.6 реализация этой спецификации представлена javascript-движоком Rhino. Однако применение целого script-движка для обычного вычисления формул будет довольно неоправданным решением. Мой поиск привел к Janino - это целый фреймворк для динамической компиляции и исполнения java. То есть он позволяет выполнять скрипты на java внутри самой java. Одно из его призваний это компиляция и выполнение различных математических выражений с помощью org.codehaus.janino.ExpressionEvaluator.

Я решил сравнить производительность Rhino и Janino. Для теста выбрал простую формулу: (x-10)*Math.sin(0.1)*2, вычисление которой будет осуществляться 1000000 раз.

package com.blogspot.nkoksharov;

import javax.script.*;

import org.apache.commons.lang.time.StopWatch;
import org.codehaus.janino.ExpressionEvaluator;
import org.mozilla.javascript.Context;
import org.mozilla.javascript.ContextFactory;
import org.mozilla.javascript.Function;
import org.mozilla.javascript.Scriptable;
import org.testng.annotations.Test;

public class ExpressionTest {

    @Test
    public void testRhino() throws ScriptException {
        ScriptEngineManager scriptManager = new ScriptEngineManager();
        ScriptEngine se = scriptManager.getEngineByName("JavaScript");
        SimpleBindings bindings = new SimpleBindings();
        bindings.put("x", 2);

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        for (int i = 0; i < 1000000; i++) {
            Double result = (Double) se.eval("(x-10)*Math.sin(0.1)*2", bindings);
        }
        stopWatch.stop();
        System.out.println("JDK Rhino time: " + stopWatch);
    }

    @Test
    public void testRhinoFunc() throws ScriptException, NoSuchMethodException {
        ScriptEngineManager scriptManager = new ScriptEngineManager();
        ScriptEngine se = scriptManager.getEngineByName("JavaScript");

        String script = "function count(x) { return (x-10)*Math.sin(0.1)*2; }";
        se.eval(script);

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        for (int i = 0; i < 1000000; i++) {
            Invocable inv = (Invocable) se;
            Double result = (Double) inv.invokeFunction("count", 2);
        }
        stopWatch.stop();
        System.out.println("JDK Rhino func time: " + stopWatch);
    }

    @Test
    public void testNativeRhinoCompiledFunc() {
        ContextFactory cf = new ContextFactory();
        Context cx = cf.enterContext();
        Scriptable scope = cx.initStandardObjects();
        Function f = cx.compileFunction(scope, "function count(x) { return (x-10)*Math.sin(0.1)*2; }", null, 0, null);

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        for (int i = 0; i < 1000000; i++) {
            Double value = (Double) f.call(cx, scope, scope, new Object[] {2});
        }
        stopWatch.stop();
        System.out.println("Mozilla Rhino compiled-func time: " + stopWatch);
    }

    @Test
    public void testJanino() throws Exception {
        ExpressionEvaluator ee = new ExpressionEvaluator("(x-10)*Math.sin(0.1)*2",
            Double.class, new String[] {"x"}, new Class[] {Integer.class});

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        for (int i = 0; i < 1000000; i++) {
            Double result = (Double) ee.evaluate(new Object[] {2});
        }
        stopWatch.stop();
        System.out.println("Janino time: " + stopWatch);
    }
}

Результат вполне оправдал мои ожидания:

                                 (ч:мм:сс.мс)
                  JDK Rhino time: 0:01:50.061
             JDK Rhino func time: 0:00:59.040
Mozilla Rhino compiled-func time: 0:00:00.344
                     Janino time: 0:00:00.156

В итоге получается, что скорость выполнения с Rhino использующейся в JDK заметно отстает от Janino, даже не смотря на выполнение через javascript-функцию. Однако, если вы будете использовать реализацию Rhino от Mozilla, с возможностью компиляции в bytecode, то получите лишь 2-х кратное отставание по скорости. И так первенство у Janino, который также компилирует выражения перед выполнением. При этом обращения к методу ExpressionEvaluator.evaluate будут thread-safe.

Генерация javabean в runtime

Если требуется создать javabean в runtime по набору полей, то никакими стандартными средствами java эту задачу решить не удастся.

По началу я решил, что с этой задачей может справиться какая-либо из реализаций org.apache.commons.beanutils.DynaBean. Однако работать с ним можно лишь так if (object instanceof DynaBean) ... . То есть, если модуль использующий этот объект работает с ним только через reflection и ничего не знает о DynaBean, то такое решение не подходит.

В итоге, было решено использовать Javassist. Очень удобный инструмент для подобного рода действий, позволяет производить как создание так и модификацию уже загруженных JVM классов. Предоставляет два вида API, на уровне исходного кода и собственно самого байткода. Использовать конечно лучше первый, т.к. мало кого устроит работать напрямую с байткодом.

В альтернативу classloader-у используется класс javassist.ClassPool, он позволяет не только загружать, но и создавать классы javassist.CtClass. При этом класс не будет доступен приложению сразу же, а лишь после преобразования в обычный класс java.lang.Class. Сам javassist.CtClass обладает богатыми возможностями для создания, удаления методов и полей, изменения наследования или даже названия уже загруженного класса. Для доступа ко всем классам загруженным JVM следует использовать ClassPool.getDefault(), хотя можно реализовать и свой, чтобы, например, загружать классы самостоятельно.

Итак, решение с использованием Javassist будет выглядеть так:

public Class<?> createClass(String className, Map<String, Class<?>> props) throws Exception {
 ClassPool classPool = ClassPool.getDefault();
 CtClass cc = classPool.makeClass(className);
 
 for (Entry<String, Class<?>> entry : props.entrySet()) {
  String name = entry.getKey();
  Class<?> type = entry.getValue();
  CtClass fieldType = classPool.get(type.getName());
  CtField field = new CtField(fieldType, name, cc);
  cc.addField(field);
  
  String n = camelize(name);
  CtMethod setter = CtNewMethod.setter("set" + n, field);
  cc.addMethod(setter);
  CtMethod getter = CtNewMethod.getter("get" + n, field);
  cc.addMethod(getter);
 }
 
 return cc.toClass();
}
 
private String camelize(String s) {
 return s.substring(0, 1).toUpperCase() + s.substring(1);
}

Log4jdbc логгер для sql-запросов

Log4jdbc представляет собой jdbc-драйвер, который может логировать sql-вызовы используя SLF4J. Реализует как JDBC 3 так и JDBC 4 спецификации. Для настройки к вашему jdbc-url необходимо просто добавить префикс jdbc:log4. Например:

jdbc:postgresql://localhost:5432/test, заменить на jdbc:log4jdbc:postgresql://localhost:5432/test

Затем в log4j.xml или log4j.properties настроить logger на любую из категорий:

• jdbc.sqlonly - логирование только sql запросов,

• jdbc.sqltiming - логирование sql-запросов и их времени выполнения,

• jdbc.audit - логирование всех jdbc-операций за исключением ResultSet-ов,

• jdbc.resultset - самое полное логирование, включающее в себя операции со всеми ResultSet-объектами,

• jdbc.connection - логирование операций с jdbc-соединениями

Отключение кэширования html-страницы. Часть 2

Использование meta-тэгов, описываемых в первой части помогает нам избавиться от кэширования в браузере. Однако, помимо кэша браузера существует кэш прокси-сервера, который проводит анализ лишь HTTP-заголовков. К тому же может появится необходимость отключить кэширование не только самой html-страницы, но и ресурсов, находящихся на ней (jpg, swf ...). Данную проблему можно решить таким вот servlet-фильтром:

package ru.someone;

import java.io.IOException;
import java.util.*;
import javax.servlet.*;
import org.slf4j.*;

public class ResponseHeaderFilter implements Filter {

    private final Logger log = LoggerFactory.getLogger(getClass());
    private final Map httpParams = new HashMap();

    public void init(FilterConfig filterConfig) throws ServletException {
        Enumeration enums = filterConfig.getInitParameterNames();
        while(enums.hasMoreElements()) {
            final String name = enums.nextElement();
            final String value = filterConfig.getInitParameter(name);
            log.debug("HTTP-header registred - {}:{}", name, value);
            httpParams.put(name, value);
        }
    }

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletResponse httpResponse = (HttpServletResponse) response;
        for (Entry entry : httpParams.entrySet()) {
            httpResponse.setHeader(entry.getKey(), entry.getValue());
        }
        chain.doFilter(request, response);
    }

    public void destroy() {
    }

}

Этот фильтр выставляет HTTP-заголовки, объекту javax.servlet.HttpServletResponse, которые берет из конфигурации фильтра. Соответственно в самом web.xml нужно написать:

<filter>
     <filter-name>responseHeaderFilter</filter-name>
        <filter-class>ru.someone.ResponseHeaderFilter</filter-class>
        <init-param>
            <param-name>Cache-Control</param-name>
            <param-value>no-store, max-age=0, must-revalidate</param-value>
        </init-param>
        <init-param>
            <param-name>Pragma</param-name>
            <param-value>no-cache</param-value>
        </init-param>
        <init-param>
            <param-name>Expires</param-name>
            <param-value>Fri, 01 Jan 1990 00:00:00 GMT</param-value>
        </init-param>
</filter>
<filter-mapping>
     <filter-name>responseHeaderFilter</filter-name>
     <url-pattern>*.jpg</url-pattern>
</filter-mapping>
<filter-mapping>
     <filter-name>responseHeaderFilter</filter-name>
     <url-pattern>*.swf</url-pattern>
</filter-mapping>

Slf4j на смену commons-logging

Наверное каждый из вас знаком с commons-logging. Однако пользы от него не так много. Наличие трюков с class-loader-ами, а также излишнее использование reflection-а и отсутствие возможности использования параметризированных сообщений, мягко говоря огорчают.

Довольно популярной заменой commons-logging является Slf4j (Simple Logging Framework for Java). Во-первых, в нем реализована поддержка MDC (пока что такая возможность реализована в logback и log4j). Этот механизм удобно использовать, когда у вас в контексте одного потока в лог записывается много параметра, которые действительны только для данного контекста. Например, для каждого сообщения необходимо выводить также имя пользователя, его логин и т.д. Вместо того чтобы указывать эти параметры каждый раз в сообщении. Можно положить их в MDC-контекст:

MDC.put("ipAddress", request.getRemoteAddr());
Principal user = request.getUserPrincipal();
MDC.put("user", user.getName());

И указать в ConversionPattern log4j эти параметры:

%X{ipAddress} - %X{user} %n%m

Во-вторых, есть наличие параметризованных сообщений. То есть, если раньше надо было писать так:

logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));

Если у нас будет не debug уровень, то будет тратиться время на сборку строки, которая не будет выводиться. Потому надо будет написать так:

if(logger.isDebugEnabled()) { 
     logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
}

Используя Slf4j все это можно заменить одной строкой:

logger.debug("Value {} was inserted between {} and {}.", 
     new Object[] {newVal, below, above});

Символами {} как раз и обозначаются параметры строки, которые передаются последним аргументом. При этом сборка строки не будет производиться при уровне ниже чем debug.

В-третьих, сама архитектура представляет собой два модуля, api slf4j-api.jar и реализация slf4j-XXXXX.jar. Реализация представлена 6-ью модулями:

На главной странице этого проекта перечислены проекты, которые используют данный фреймворк и их число растет.

Пример использования:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

class TestClass {

 private final Logger log = LoggerFactory.getLogger( TestClass.class ); 

 ...

 log.debug( "..." );
}