ConnectionRecoveryManager's extensibility

[Esteban Franqueiro <es...@bea.com>]

Hi all.
In order to support obtaining the connection for the data store from a different DataSource than the 
one used in ConnectionFactory (since I'm not using JNDI), or from the DriverManager, I had to modify 
ConnectionRecoveryManager to make it extensible.
I was wondering why this class is not extensible in the first place.
Basically, all that has to be done is make setupConnection() and related fields protected.
I would also add a protected constructor that allows to skip the call to setupConnection(), so it 
can be called in the derived class' constructor instead.
Regards,

Esteban Franqueiro
esteban.franqueiro@bea.com 


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Re: ConnectionRecoveryManager's extensibility

[Esteban Franqueiro <es...@bea.com>]

> That sounds complicated. What about if you use a 'wrapper driver' that
> allows you to use use the standard way to get a connection? Like this:

Actually is not complicated at all, provided I can extend ConnectionRecoveryManager, which I can't 
:)
Just provide a new setupConnection() method in a subclass.
Regards,

Esteban Franqueiro
esteban.franqueiro@bea.com 


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Re: ConnectionRecoveryManager's extensibility

[Thomas Mueller <th...@gmail.com>]

Hi,

>  On one hand I'm using a data source, but it's not obtained via JNDI, but via Spring, so the ConnectionFactory doesn't suit my needs.
>  On the other, we're using branded drivers that need to be unlocked. To cover all cases, it's better
>  to unlock the connections right after creating them rather than when using them. In the case of the
>  DataStore, this has to be done in ConnectionRecoveryManager.setupConnection() which is the method
>  that actually instantiates the connection. The problem is that this method is private.

That sounds complicated. What about if you use a 'wrapper driver' that
allows you to use use the standard way to get a connection? Like this:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.DriverPropertyInfo;
import java.sql.SQLException;
import java.util.Properties;

public class Wrapper implements java.sql.Driver {

    private static final Wrapper INSTANCE = new Wrapper();
    private static final String PREFIX = "jdbc:wrapper:";

    static {
        try {
            DriverManager.registerDriver(INSTANCE);
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    public boolean acceptsURL(String url) throws SQLException {
        return url != null && url.startsWith(PREFIX);
    }

    public Connection connect(String url, Properties info) throws SQLException {
        if (!acceptsURL(url)) {
            return null;
        }
        url = "jdbc:" + url.substring(PREFIX.length());
        // or open a connection in some other way
        Connection conn = DriverManager.getConnection(url, info);
        // unlock ...
        return conn;
    }

    public int getMajorVersion() {
        return 1;
    }

    public int getMinorVersion() {
        return 0;
    }

    public DriverPropertyInfo[] getPropertyInfo(String url, Properties
prop) throws SQLException {
        return new DriverPropertyInfo[0];
    }

    public boolean jdbcCompliant() {
        return true;
    }

}

Regards,
Thomas

Re: ConnectionRecoveryManager's extensibility

[Esteban Franqueiro <es...@bea.com>]

Hi.

> I don't fully understand your use case, what data source do you use,
> and why can't you use the standard way to get a connection?

On one hand I'm using a data source, but it's not obtained via JNDI, but via Spring, so the 
ConnectionFactory doesn't suit my needs.
On the other, we're using branded drivers that need to be unlocked. To cover all cases, it's better 
to unlock the connections right after creating them rather than when using them. In the case of the 
DataStore, this has to be done in ConnectionRecoveryManager.setupConnection() which is the method 
that actually instantiates the connection. The problem is that this method is private.
I hope you can understand now.
Regards,

Esteban Franqueiro
esteban.franqueiro@bea.com 


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Re: ConnectionRecoveryManager's extensibility

[Thomas Mueller <th...@gmail.com>]

Hi,

>  In order to support obtaining the connection for the data store from a different DataSource than the
>  one used in ConnectionFactory (since I'm not using JNDI), or from the DriverManager, I had to modify
>  ConnectionRecoveryManager to make it extensible.
>  I was wondering why this class is not extensible in the first place.
>  Basically, all that has to be done is make setupConnection() and related fields protected.
>  I would also add a protected constructor that allows to skip the call to setupConnection(), so it
>  can be called in the derived class' constructor instead.

I don't fully understand your use case, what data source do you use,
and why can't you use the standard way to get a connection?

Regards,
Thomas