How does FlexyPool support both Connection proxies and decorators

Proxies

FlexyPool monitors connection pool usage and so it needs to intercept the connection close method call.
For simplicity sake, the first version was relying on dynamic proxies for this purpose:

private static class ConnectionInvocationHandler 
    implements InvocationHandler {

    public static final String CLOSE_METHOD_NAME = "close";

    private final Connection target;
    private final ConnectionCallback callback;

    public ConnectionInvocationHandler(
        Connection target, 
        ConnectionCallback callback) {
        this.target = target;
        this.callback = callback;
    }

    @Override
    public Object invoke(
        Object proxy, 
        Method method, 
        Object[] args) throws Throwable {
        if (CLOSE_METHOD_NAME.equals(method.getName())) {
            callback.close();
        }
        return method.invoke(target, args);
    }
}

As straightforward as it may be, a proxy invocation is slower than a decorator, which calls the target method using a direct invocation.
Because all connection pools use proxies anyway, adding another proxy layer only adds more call-time overhead and so now FlexyPool supports connection decorators as well.

Decorators

A ConnectionDecorator wraps an underlying database connection, delegating all calls to the actual object instance. Just like its proxy counterpart, oOnly the close method is doing any extra logic:

public class ConnectionDecorator 
    implements Connection {

    private final Connection target;

    private final ConnectionCallback callback;

    public ConnectionDecorator(
        Connection target, 
        ConnectionCallback callback) {
        this.target = target;
        this.callback = callback;
    }

    public Connection getTarget() {
        return target;
    }

    public ConnectionCallback getCallback() {
        return callback;
    }

    @Override
    public Statement createStatement() 
        throws SQLException {
        return target.createStatement();
    }
    
    @Override
    public void close() 
        throws SQLException {
        callback.close();
        target.close();
    }
    
    /**
     *  More methods omitted for brevity sake
     */

    public void setSchema(String schema) 
        throws SQLException {
        ReflectionUtils.invoke(
            target,
            ReflectionUtils.getMethod(
                target, 
                "setSchema", 
                String.class
            ),
            schema
        );
    }

    public String getSchema() 
        throws SQLException {
        return ReflectionUtils.invoke(
            target,
            ReflectionUtils.getMethod(
                target, 
                "getSchema"
            )
        );
    }

    public void abort(Executor executor) 
        throws SQLException {
        ReflectionUtils.invoke(
            target,
            ReflectionUtils.getMethod(
                target, 
                "abort", 
                Executor.class
            ),
            executor
        );
    }

    public void setNetworkTimeout(
        Executor executor, 
        int milliseconds) 
        throws SQLException {
        ReflectionUtils.invoke(
            target,
            ReflectionUtils.getMethod(
                target, 
                "setNetworkTimeout", 
                Executor.class, 
                int.class
            ),
            executor, 
            milliseconds
        );
    }

    public int getNetworkTimeout() 
        throws SQLException {
        return (Integer) 
            ReflectionUtils.invoke(
                target,
                ReflectionUtils.getMethod(
                    target, 
                    "getNetworkTimeout"
                )
            );
    }
}

As you might have noticed already, some methods use Java Reflection instead of a direct method call:

These methods have been added to Java 1.7 and a direct call will fail when compiling the project with Java 1.6.
Because Java 1.6 is the minimum requirement for most FlexyPool modules, these methods forward the incoming method call through a Java reflection invocation.
Omitting these methods is not optional either because on a 1.7 JVM, the Connection decorator will not have these methods and a class loading error will be thrown.

On projects using at least Java 1.7, FlexyPool also offers the Java7ConnectionDecorator:

public class Java7ConnectionDecorator 
    extends ConnectionDecorator {

    public Java7ConnectionDecorator(
        Connection target, 
        ConnectionCallback callback) {
        super(target, callback);
    }

    @Override
    public void setSchema(String schema) 
        throws SQLException {
        getTarget().setSchema(schema);
    }

    @Override
    public String getSchema() 
        throws SQLException {
        return getTarget().getSchema();
    }

    @Override
    public void abort(Executor executor) 
        throws SQLException {
        getTarget().abort(executor);
    }

    @Override
    public void setNetworkTimeout(
        Executor executor, 
        int milliseconds) 
        throws SQLException {
        getTarget().setNetworkTimeout(executor, milliseconds);
    }

    @Override
    public int getNetworkTimeout() 
        throws SQLException {
        return getTarget().getNetworkTimeout();
    }
}

This class is not part of the core library, being included in a separated Java 1.7 compliant module.
To make use of it, you need to add the following Maven dependency:

<dependency>
    <groupId>com.vladmihalcea.flexy-pool</groupId>
    <artifactId>flexy-pool-core-java7</artifactId>
    <version>${flexy-pool.version}</version>
</dependency>

The service discovery mechanism

From the very beginning, FlexyPool has offered support for configuring the ConnectionProxyFactory instance, so switching to decorators didn’t require any intensive code refactoring.

Prior to release 1.2.4 the default connection provider was the JdkConnectionProxyFactory, which uses dynamic proxies.
Since 1.2.4, FlexyPool uses connection decorators as the default connection intercepting mechanism.

The actual decorator version is resolved at runtime and the loading mechanism is built out of the following components:

FlexyPoolConnectionProxyDecorator

The actual connection decorator factory is resolved by the following method:

public ConnectionDecoratorFactory resolve() {
    int loadingIndex = Integer.MIN_VALUE;
    ConnectionDecoratorFactory connectionDecoratorFactory = null;
    Iterator<ConnectionDecoratorFactoryService> 
        connectionDecoratorFactoryServiceIterator = serviceLoader.iterator();
    while (connectionDecoratorFactoryServiceIterator.hasNext()) {
        try {
            ConnectionDecoratorFactoryService connectionDecoratorFactoryService = 
                connectionDecoratorFactoryServiceIterator.next();
            int currentLoadingIndex = connectionDecoratorFactoryService.loadingIndex();
            if (currentLoadingIndex > loadingIndex) {
                ConnectionDecoratorFactory currentConnectionDecoratorFactory = 
                    connectionDecoratorFactoryService.load();
                if (currentConnectionDecoratorFactory != null) {
                    connectionDecoratorFactory = currentConnectionDecoratorFactory;
                    loadingIndex = currentLoadingIndex;
                }
            }
        } catch (LinkageError e) {
            LOGGER.info("Couldn't load ConnectionDecoratorFactoryService on the current JVM", e);
        }
    }
    if (connectionDecoratorFactory != null) {
        return connectionDecoratorFactory;
    }
    throw new IllegalStateException("No ConnectionDecoratorFactory could be loaded!");
}

Just like the MetricsFactory, each connection decorator factory has an associated Service Provider. Multiple such Service Providers can be loaded at runtime (the default Java 1.6 connection decorator service or the Java 1.7 one). The selection is done based on the index (latest Java version take precedence) and the current JVM JDBC version support (the Java 1.7 connection decorator won’t be resolved on a Java 1.6 runtime environment).

If you enjoyed this article, I bet you are going to love my book as well.

Conclusion

Decorators incur more configuration overhead than a proxy but if you want to squeeze the last performance drop it’s worth considering the direct method call advantage.

Enter your email address to follow this blog and receive notifications of new posts by email.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s