proxool-developer — Developer's discussion list

[Proxool-developer] ProxoolDataSource supporting all three configuration modes checked in

[<chr...@em...>]

I have done some refactoring.

There is now only one Proxool DataSource:
ProxoolDataSource (surprise surprise)

It transparently supports three modes of configuration:
- pre-configured (Usefull for people who wants to use data sources 
outside of a J2EE environment)
- bean-configured (Used by containers such as Jetty and Resin)
- factory-configured (Used by containers such as Tomcat )

I have also added tests for all three modes in ProxooDataSourceTest.

Tomorrow I start testing in various containers.

There are still plenty of details to work out. I'll return to that in 
other mails.

CHR

[Proxool-developer] Wrapped Exceptions

[Bill H. <bi...@lo...>]

I have nearly finished implementing wrapped connections. This means that
every time we serve a connection then we wrap it up in a disposable
object. That way, once it is closed (i.e. returned to the pool) then
subsequent operations no longer mess with the internal connection (which
might be being used by someone else by this point).

Anyone know how a Connection should behave if you close it and then do
something to it? Here's a list of all the methods (for JDK 1.4). I've
grouped them into:

Should still work:
  isClosed
  hashcode
  finalize (protected anyway)
  clone ?
  equals
  toString

Should throw an exception:
  clearWarnings
  commit
  createStatement
  getWarnings
  prepareCall
  prepareStatement
  releaseSavepoint
  rollback

Should be silently ignored:
  close (API says it is a no-op)

I think that all of these should probably throw an exception:
  getAutoCommit
  getHoldability
  getTransactionIsolation
  getTypeMap
  isReadOnly
  nativeSQL
  setAutoCommit
  setCatalog
  setHoldability
  setReadOnly
  setSavepoint
  setSavepoint
  setTransactionIsolation
  setTypeMap

- Bill

Re: [Proxool-developer] Proxool behavior when max connection reached

[Bill H. <bi...@lo...>]

Bertrand,

On Wed, 2004-03-17 at 21:20, Bertrand Renuart wrote:

> (tell me if I'm wrong)

You're not.

> I was thinking about a more flexible approach: *hard* and *soft* limit (a
> bit like the disk quotas):
> - soft limit: when the soft limit is reached, new connection requests are
> blocked until one becomes available;
> - hard limit: an exception is thrown when the number of used
> connections+queued connections reaches the hard limit

It's a useful idea. We would have to be defensive in making sure that
the queue of waiting threads didn't get out of hand. But having a hard
limit should solve that. 

+1 (for post 1.0)

- Bill

(Keep it up with the ideas - and add this one as a feature request)

[Proxool-developer] Proxool behavior when max connection reached

[Bertrand R. <ber...@mo...>]

Currently, if the maximum connection count is reached and none is available,
Proxool will throw an SQLException if one tries to obtain a new connection
from the pool.

(tell me if I'm wrong)

In some cases one would expect his request to block until one becomes
available or a timeout occurs (a bit like blocking IO).

I remember this issue in a previous thread. Bill's answer was:
- dimension your max connection properly taking the maximum concurrent user
your application can accept (scaling issue);
- if the limit is reached - then your application has probably reached its
limit too. Therefore queueing the new request won't help and will even
contribute to DOS of your app.

Well... Yes and no :)

There are situations were you want to limit the number of real connections
to your database independently of other factors. For licensing reasons for
example (you are licensed to 10 simultaneous connections) or because of
company policies (your DB is shared with others and your DBA doesn't give
you more than x connections), etc.


I was thinking about a more flexible approach: *hard* and *soft* limit (a
bit like the disk quotas):
- soft limit: when the soft limit is reached, new connection requests are
blocked until one becomes available;
- hard limit: an exception is thrown when the number of used
connections+queued connections reaches the hard limit

(soft limit == hard limit == current behavior)


Comments ?



-bertrand

(will come with new ideas every night ;)

Re: [Proxool-developer] Some ideas about future dev

[Bill H. <bi...@lo...>]

Bertrand,

On Tue, 2004-03-16 at 22:35, Bertrand Renuart wrote:

> 1/ Externalize ConnectionTest

Sounds good. Presumably, if any of the registered testers failed then
the connection would be discarded.

> 2/ Externalize Prototyping / Connection creation
[snip]
> I remember someone's post that had problems because he needed to change the
> current thread's user identity before getting a connection 

Yes, I believe that would fix his problem. Not 100% sure though.

> _________________________________
> 3/ Externalize ConnectionResetter

I suppose that would allow people to do things like switch autoCommit
off, and the like.

--

All of these suggestions are good. I would schedule them for after
release 1.0. The criteria for getting into 1.0 are:

1) Increased robustness or bug fixes

2) A "required" feature of a connection pool (like DataSource)

3) Something that will be so useful that it will help make Proxool the
best (like simplified, flexible configuration)

- Bill

[Proxool-developer] Some ideas about future dev

[Bertrand R. <ber...@mo...>]

Hi everybody,

Here are some new ideas about the future of Proxool:

_____________________________
1/ Externalize ConnectionTest

Currently, Proxool test the viability of a connection by executing the test
SQL statement provided by the configuration.
Would be nice if users could plug their own connection validation logic.

The connection would be validated using a ConnectionTesterIF.
The default implementation would use the SQL provided by the configuration.
User would have the ability to register their own implementation.

________________________________________________
2/ Externalize Prototyping / Connection creation

The same idea would apply to the connection creation.
Currently, the Prototyper is a class and there is no way to substitute it
with another implementation for a particular pool.

Still don't see why one would do this... But it some cases people may want
to obtain the *real* connection from their database themselves...

I remember someone's post that had problems because he needed to change the
current thread's user identity before getting a connection (or something
similar)... Anyway, with a pluggable ConnectionCreatorIF - all kind of
configuration would be possible.

_________________________________
3/ Externalize ConnectionResetter

Same idea for the ConnectionResetter - invoked to reset the connection to a
default/known state when it is returned to the pool.

Note: this one is probably less interesting...



Feel free to comment :)


-bertrand

Re: [Proxool-developer] ProxoolDataSource initail version checked in

[Bill H. <bi...@lo...>]

CHR,

On Tue, 2004-03-16 at 00:11, Christian Nedreg=E5rd wrote:

> I have checked in the initial version of the Proxool container managed=20
> DataSource. It is suposed to be instantiated, have its properties=20
> populated, and be deployed to JNDI by a (J2EE) container.

I'm looking forward to looking at all that. Great stuff.

> I seem to get this message everytime I check something in:
>=20
> Mailing pro...@li......
> Generating notification message...
> Generating notification message... done.
> Mailing pro...@li......
> Generating notification message...
> Traceback (most recent call last):
>   File "/cvsroot/proxool/CVSROOT/syncmail", line 322, in ?
>     main()
>   File "/cvsroot/proxool/CVSROOT/syncmail", line 315, in main
>     blast_mail(subject, people, specs[1:], contextlines, fromhost)
>   File "/cvsroot/proxool/CVSROOT/syncmail", line 221, in blast_mail
>     conn.connect(MAILHOST, MAILPORT)
>   File "/usr/lib/python2.2/smtplib.py", line 276, in connect
>     for res in socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM):
> socket.gaierror: (-2, 'Name or service not known')
>=20
> Know anything about that?

No. But I no longer get mails about commits. Do you? I tried to take a
look at the CVSROOT project yesterday to check it, but there was a
failure contacting SF so I couldn't do the checkout. Certainly, it
hasn't been changed for many months so I don't know what's going on.

- Bill

Re: [Proxool-developer] Doc bug: maximum-new-connections property is documented instead of replacement simultaneous-build-throttle

[Bill H. <bi...@lo...>]

CHR,

On Mon, 2004-03-15 at 23:31, Christian Nedreg=E5rd wrote:

> "maximum-new-connections" property is documented instead of replacement=
=20
> "simultaneous-build-throttle" here:=20
> http://proxool.sourceforge.net/properties.html

I think you should be adding these bugs into SF's bug list. That way I
won't forget them :)

- Bill

[Proxool-developer] ProxoolDataSource initail version checked in

[<chr...@em...>]

I have checked in the initial version of the Proxool container managed 
DataSource. It is suposed to be instantiated, have its properties 
populated, and be deployed to JNDI by a (J2EE) container.

There is also a small new test in DataSourceTest imitating a "micro 
container".

This datasource is not finished yet. I need to add support for some more 
properties (jmx* and test-*) and test it on some real servers.

Still coming up: The Referencable Proxool DataSource and ObjectFactory...

If anybody is wondering about the new Tyrex library I have checked in:
It is a small memory based JNDI implementation that is used for testing.

Bill:
I seem to get this message everytime I check something in:

Mailing pro...@li......
Generating notification message...
Generating notification message... done.
Mailing pro...@li......
Generating notification message...
Traceback (most recent call last):
  File "/cvsroot/proxool/CVSROOT/syncmail", line 322, in ?
    main()
  File "/cvsroot/proxool/CVSROOT/syncmail", line 315, in main
    blast_mail(subject, people, specs[1:], contextlines, fromhost)
  File "/cvsroot/proxool/CVSROOT/syncmail", line 221, in blast_mail
    conn.connect(MAILHOST, MAILPORT)
  File "/usr/lib/python2.2/smtplib.py", line 276, in connect
    for res in socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM):
socket.gaierror: (-2, 'Name or service not known')

Know anything about that?

CHR

[Proxool-developer] Doc bug: maximum-new-connections property is documented instead of replacement simultaneous-build-throttle

[<chr...@em...>]

"maximum-new-connections" property is documented instead of replacement 
"simultaneous-build-throttle" here: 
http://proxool.sourceforge.net/properties.html

CHR

[Proxool-developer] Doc bug: house-keeping-test-sql is documented twice.

[<chr...@em...>]

house-keeping-test-sql is documented twice here:
http://proxool.sourceforge.net/properties.html

CHR

[Proxool-developer] Developer Doc Idea

[Bill H. <bi...@lo...>]

Hi all,

I'd like to document some of the thinking behind decisions we've made.
Like why we have repackaged commons-logging internally, for instance. It
would be like a summary of posts on this list without having to search
around joining up all the threads to find the whole picture. Anyone else
have any other candidate articles?

While we're talking about doc, Nat is making some progress on DocBook so
I hope to make the whole documentation a lot more accessible very soon.

- Bill

[Proxool-developer] Proxool DataSource inital chek-ins

[<chr...@em...>]

HELO Proxool.

I'm back from hibernation.

I've started to check in the DataSource stuff.

Today all you get is the extremely simple ProxoolManagedDataSource wich 
simply knows a pool alias, and delegates calls to "getConnection" to 
that pool.

This DataSource is useful for people who wants to use data sources 
outside of a J2EE environment. Proxool will create and bind this 
datasource if the "jndi-name" property is set.

I have taken a slightly different approach to the InitialContext 
configuration than what we planned before. Previously we had defined 
constants for the set of JNDI configuration properties Proxool could 
recognise. This is problematic because different JNDI providers will 
have different properties. I have chosen a more generic approach: 
Proxool will now pass all parameters prefixed with "jndi-" on to the 
InitialContext. See the DataSourceTest testcase to for how it is used. 
Is this approach ok?

I have some questions:

    * I have added a jndi package to the admin package. Is this the
      rigth place to put it?
    * The Proxool api currently prevents us from supporting the
      getConnection(user, pwd) DataSource method. How can we fix this?


Tomorrow I'll hopefully check in the other two Proxool DataSources: 
ProxoolDataSource and ReferencableProxoolDataSource.
The first is the standard Proxool DataSource that will be configured by 
a J2EE server via bean properties, the second is a subcalss of this that 
will facilitate DataSource configuration, creation  and serialization 
via standard JNDI protocols.

Theres also lots of other stuff we need to discuss. For instance: We 
should make our DataSources implement ConnectionPoolDataSource. This 
will force us to make our proxy connections implement PooledConnection. 
We must also create some adapters between the PooledConnection event 
mechanism and the Proxool event mechanism.

More about this and other stuff in the morrow.

Sorry for dissapearing.

CHR

RE: [Proxool-developer] CodeReview - AbstractListenerContainer

[Bertrand R. <ber...@mo...>]

Thx
Will do it as soon as I have some time left...


> -----Original Message-----
> From: pro...@li...=20
> [mailto:pro...@li...] On=20
> Behalf Of Christian Nedreg=E5rd
> Sent: samedi 13 mars 2004 15:37
> To: 'Proxool Developer List'
> Subject: Re: [Proxool-developer] CodeReview -=20
> AbstractListenerContainer
>=20
>=20
>=20
> Good :)
>=20
> Thats my piece of verbose code. Have Bill given you commit=20
> rights yet?=20
> If so feel free to replace it with what you suggest.
>=20
> CHR
>=20

Re: [Proxool-developer] CodeReview - AbstractListenerContainer

[<chr...@em...>]

Good :)

Thats my piece of verbose code. Have Bill given you commit rights yet? 
If so feel free to replace it with what you suggest.

CHR


Bertrand Renuart wrote:

> I had a look at the AbstractListenerContainer... and found it much 
> complex for what it is supposed to do.
>  
> Let's recap the (supposed) requirements:
> - fast access to the list of registered listeners - frequent (read);
> - must support concurrency;
> - add/remove can be slower and are less frequent (update)
>  
>  
> The following implementation makes use of an object array to store the 
> reference to registered listeners.
> Every time add/remove is called, a new array is created with the new 
> state - the original is *not modified* but *replaced* by a new one. 
> This behavior is important since it guarantees that once you got the 
> array, you know it will *never been modified while you play with it*. 
> Thanks to this trick, no need for read/write locks and a fast access 
> to the list ;-)
>  
> The only precaution now is to make sure that only one thread can 
> access add/remove at a time. This code is protected by synchronized 
> statement - which is not a penality since modifications are not frequent.
>  
>  
> Classes extending this container can get access to the list of 
> registered listener by calling the protected /getListeners()/ method 
> that returns a reference to the array.
> It is now enough to iterate through the array with a simple for loop. 
> That's another benefit: no need to construct an iterator every time we 
> have to deliver an event...
>  
>  
> All this is definitly less expensive than the current implementation 
> that makes heavy use of synchronized statements :(
>  
>  
> The (new) code is below.
> Feel free to send any comments :)
>  
>
> public abstract class AbstractFastListenerContainer implements 
> ListenerContainerIF
> {
>     static final Log LOG = 
> LogFactory.getLog(AbstractFastListenerContainer.class);
>    
>     private Object[] listeners = EMPTY_LISTENERS;
>     private static final Object[] EMPTY_LISTENERS = new Object[]{};
>
>     /**
>      * @see ListenerContainerIF#addListener(Object)
>      */
>     public synchronized void addListener(Object listener)
>     {
>         // create a new array
>         Object[] newListeners = new Object[listeners.length];
>        
>         // copy listeners currently registered
>         System.arraycopy(listeners, 0, newListeners, 0, listeners.length);
>        
>         // add the new one
>         newListeners[listeners.length] = listener;
>        
>         // commit changes
>         listeners = newListeners;
>     }
>    
>    
>     /**
>      * @see ListenerContainerIF#removeListener(Object)
>      */
>     public synchronized boolean removeListener(Object listener)
>     {
>         // find listener to remove in the list
>         int index=-1;
>         for(int i=0; i<listeners.length; i++) {
>             if( listeners[i]==listener ) {
>                 index = i;
>                 break;
>             }
>         }
>        
>         // not found ?
>         if( index==-1 )
>             return false;
>        
>         // create a new array of the right size
>         Object[] newListeners = new Object[listeners.length-1];
>        
>         // copy registered listeners minus the one to remove
>         if( index > 0 )
>             System.arraycopy(listeners, 0, newListeners, 0, index);
>        
>         if( index < listeners.length-1 )
>             System.arraycopy(listeners, index+1, newListeners, index, 
> listeners.length-index-1);
>        
>         // commit
>         listeners = newListeners;
>         return true;
>     }
>
>    
>     /**
>      * Get a reference to the array containing registered listeners
>      */
>     protected Object[] getListeners() {
>         return listeners;
>     }
>
>
>     /**
>      * @see ListenerContainerIF#isEmpty()
>      */
>     public boolean isEmpty() {
>         return listeners.length==0;
>     }
> }
>
>  
>
>  
>

[Proxool-developer] CodeReview - AbstractListenerContainer

[Bertrand R. <ber...@mo...>]

I had a look at the AbstractListenerContainer... and found it much =
complex
for what it is supposed to do.
=20
Let's recap the (supposed) requirements:
- fast access to the list of registered listeners - frequent (read);
- must support concurrency;
- add/remove can be slower and are less frequent (update)
=20
=20
The following implementation makes use of an object array to store the
reference to registered listeners.
Every time add/remove is called, a new array is created with the new =
state -
the original is *not modified* but *replaced* by a new one. This =
behavior is
important since it guarantees that once you got the array, you know it =
will
never been modified while you play with it. Thanks to this trick, no =
need
for read/write locks and a fast access to the list ;-)
=20
The only precaution now is to make sure that only one thread can access
add/remove at a time. This code is protected by synchronized statement -
which is not a penality since modifications are not frequent.
=20
=20
Classes extending this container can get access to the list of =
registered
listener by calling the protected getListeners() method that returns a
reference to the array.
It is now enough to iterate through the array with a simple for loop. =
That's
another benefit: no need to construct an iterator every time we have to
deliver an event...
=20
=20
All this is definitly less expensive than the current implementation =
that
makes heavy use of synchronized statements :(
=20
=20
The (new) code is below.
Feel free to send any comments :)
=20

public abstract class AbstractFastListenerContainer implements
ListenerContainerIF=20
{
    static final Log LOG =3D
LogFactory.getLog(AbstractFastListenerContainer.class);
   =20
    private Object[] listeners =3D EMPTY_LISTENERS;
    private static final Object[] EMPTY_LISTENERS =3D new Object[]{};

    /**
     * @see ListenerContainerIF#addListener(Object)
     */
    public synchronized void addListener(Object listener)=20
    {
        // create a new array
        Object[] newListeners =3D new Object[listeners.length];
       =20
        // copy listeners currently registered
        System.arraycopy(listeners, 0, newListeners, 0, =
listeners.length);
       =20
        // add the new one
        newListeners[listeners.length] =3D listener;
       =20
        // commit changes
        listeners =3D newListeners;
    }
   =20
   =20
    /**
     * @see ListenerContainerIF#removeListener(Object)
     */
    public synchronized boolean removeListener(Object listener)=20
    {
        // find listener to remove in the list
        int index=3D-1;
        for(int i=3D0; i<listeners.length; i++) {
            if( listeners[i]=3D=3Dlistener ) {
                index =3D i;
                break;
            }
        }
       =20
        // not found ?
        if( index=3D=3D-1 )
            return false;
       =20
        // create a new array of the right size
        Object[] newListeners =3D new Object[listeners.length-1];
       =20
        // copy registered listeners minus the one to remove
        if( index > 0 )
            System.arraycopy(listeners, 0, newListeners, 0, index);
       =20
        if( index < listeners.length-1 )
            System.arraycopy(listeners, index+1, newListeners, index,
listeners.length-index-1);
       =20
        // commit
        listeners =3D newListeners;
        return true;
    }

   =20
    /**
     * Get a reference to the array containing registered listeners
     */
    protected Object[] getListeners() {
        return listeners;
    }


    /**
     * @see ListenerContainerIF#isEmpty()
     */
    public boolean isEmpty() {
        return listeners.length=3D=3D0;
    }
}

=20

=20

Re: [Proxool-developer] Vote for Bertrand Renuart as a developer

[Nathanael U. <no...@no...>]

+1

Bill Horsman wrote:

>All,
>
>Bertrand Renuart has kindly agreed to become a Proxool Developer. We
>don't have an official procedure for adopting new developers but if
>anyone feels minded to vote on whether he is accepted or not it will be
>considered:
>
>Bertrand has been an active contributor for the past few months and has
>suggested some good patches. I think he'll be a very good addition to
>the team. He should provide some necessary skills and motivation for
>getting Proxool to 1.0 in the next few months.
>
>[On that note, I will be posting some news about our future plans and
>priorities in the next few days. I want to be really clear about what
>work remains to be done.]
>
>- Bill
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Proxool-developer mailing list
>Pro...@li...
>https://lists.sourceforge.net/lists/listinfo/proxool-developer
>
>
>  
>

[Proxool-developer] CodeReview - building connections

[Bertrand R. <ber...@mo...>]

ProxyFactory.buildProxyConnection()

Lets consider the following code from ProxyFactory (after changes we =
have
been discussing today):

    protected static ProxyConnectionIF buildProxyConnection( long id,
ConnectionPool connectionPool, int status) throws SQLException {
        final String url =3D connectionPool.getDefinition().getUrl();

        // Build the *real* connection
        Properties info =3D
connectionPool.getDefinition().getDelegateProperties();
        Connection realConnection =3D DriverManager.getConnection(url, =
info);


        // Getting null would kill us!
        if (realConnection =3D=3D null) {
            throw new SQLException("Unable to create new connection - =
got
NULL from DriverManager! - using url "+url);
        }

        // Build a proxyConnection around it - release the *real* =
connection
if it fails
        ProxyConnection proxyConnection =3D null;
        try {
            proxyConnection =3D new ProxyConnection(realConnection, id, =
url,
connectionPool, status);
        }
        catch(RuntimeException re) {
            try {
                // Ooops - unable to build the proxy - close the
realConnection
                if(realConnection!=3Dnull) realConnection.close();
            }
            finally {
                throw re;
            }
        }
      =20
        Object delegate =3D Proxy.newProxyInstance(
                realConnection.getClass().getClassLoader(),
                realConnection.getClass().getInterfaces(),
                proxyConnection);

        return (ProxyConnection) Proxy.getInvocationHandler(delegate);
    }


My question is why do we have to return a Proxy around the =
ProxyConnectionIF
we just build ? And what extra value does it had besides extending the
ProxyConnectionIF instance so it implements the java.sql.Connection
interface...
=20
This method is called from Prototype.buildConnection() that expects =
nothing
more than a ProxyConnectionIF to be returned. Moreover, when it needs a
Connection, it does an extra call to
ProxyFactory.getConnection(ProxyConnectionIF) which adds an extra Proxy
around it :-o
=20
If I understand clearly, the ProxyConnectionIF is there to store
meta-information about a *real* connection - nothing more.
The ProxyConnection class implements this interface + the =
InvocationHandler
so it can be used as a target for a Proxy implementing the Connection
interface. This way the meta-info available through the =
ProxyConnectionIF is
made up-to-date.
=20
This latest proxy is build when a connection must be returned to the =
user
from the pool (using the ProxyFactory.getConnection(ProxyConnectionIF)
method).
=20
In short, internally Proxool manipulates only ProxyConnectionIF =
instances.
=20
=20
According to me, the latest above statements in bold, could be removed -
this would remove one level of indirection.
The end of the code would be as follows:
=20
        // Build a proxyConnection around it - release the *real* =
connection
if it fails
        ProxyConnection proxyConnection =3D null;
        try {
            return new ProxyConnection(realConnection, id, url,
connectionPool, status);
        }
        catch(RuntimeException re) {
            try {
                // Ooops - unable to build the proxy - close the
realConnection
                if(realConnection!=3Dnull) realConnection.close();
            }
            finally {
                throw re;
            }
        }
     }
=20
=20
Prototyper.buildConnection()
=20
This method calls the ProxyFactory when it has to build a new =
connection.
Somewhere in the code, you can see the following:
=20
            proxyConnection =3D ProxyFactory.buildProxyConnection(id,
connectionPool, status);
            connection =3D ProxyFactory.getConnection(proxyConnection);
=20
            try {
                connectionPool.onBirth(connection);=20
            }=20
            catch (Exception e) {
                log.error("Problem during onBirth (ignored)", e);
=20
=20
It gets a new ProxyConnection then request access to a =
java.sql.Connection
through it...
It does so because of the event notification mechanism.
=20
Since the event can be exported to the outside of Proxool (users can
register event listeners) - it is important note to export the *real*
connection in the event.
Therefore, writing something like the following is not acceptable:
=20
            proxyConnection =3D ProxyFactory.buildProxyConnection(id,
connectionPool, status);
=20
            try {
                connectionPool.onBirth(proxyConnection.getConnection()); =

            }=20
            catch (Exception e) {
                log.error("Problem during onBirth (ignored)", e);
=20
Note that in the current implementation, if we don't make the =
modifications
described in point 1 above, you will have created TWO proxies (the two =
first
lines above)...
=20
Unfortunatelly, this is not consistent with the removeProxyConnection()
implementation:
=20
            try {
                onDeath(proxyConnection.getConnection());
            }=20
            catch (SQLException e) {
                log.error("Problem during onDeath (ignored)", e);
            }
=20
=20
This event notification worries me a bit... In the life of a connection, =
at
least two eventswill be thrown: onBirth and onDeath. Unfortunatelly, the
connection *instance* passed as argument will be different although it
concerns the same *real* connection. See what I mean ?
=20
To make it short:
- we can't pass the *real* connection to the listeners (for safety - =
they
cannot have access to close() or whatever... this would confuse the =
pool);
- we should always pass the same instance...
=20
Conclusion: should we pass a Proxy or tell the user not to touch the
connection in the listeners ?
=20
=20
=20
(hope this is clear - quite hard to explain all these stuff)
=20

RE: [Proxool-developer] Vote for Bertrand Renuart as a developer

[Bertrand R. <ber...@mo...>]

+1

;-)


> -----Original Message-----
> From: pro...@li... 
> [mailto:pro...@li...] On 
> Behalf Of Bill Horsman
> Sent: jeudi 11 mars 2004 15:19
> To: Proxool Developer List
> Subject: [Proxool-developer] Vote for Bertrand Renuart as a developer
> 
> 
> All,
> 
> Bertrand Renuart has kindly agreed to become a Proxool 
> Developer. We don't have an official procedure for adopting 
> new developers but if anyone feels minded to vote on whether 
> he is accepted or not it will be
> considered:
> 
> Bertrand has been an active contributor for the past few 
> months and has suggested some good patches. I think he'll be 
> a very good addition to the team. He should provide some 
> necessary skills and motivation for getting Proxool to 1.0 in 
> the next few months.
> 
> [On that note, I will be posting some news about our future 
> plans and priorities in the next few days. I want to be 
> really clear about what work remains to be done.]
> 
> - Bill
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President 
> and CEO of GenToo technologies. Learn everything from 
> fundamentals to system 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Proxool-developer mailing list Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
> 

Re: [Proxool-developer] Vote for Bertrand Renuart as a developer

[<chr...@em...>]

+1

Welcome aboard :)

CHR


Bill Horsman wrote:

>All,
>
>Bertrand Renuart has kindly agreed to become a Proxool Developer. We
>don't have an official procedure for adopting new developers but if
>anyone feels minded to vote on whether he is accepted or not it will be
>considered:
>
>Bertrand has been an active contributor for the past few months and has
>suggested some good patches. I think he'll be a very good addition to
>the team. He should provide some necessary skills and motivation for
>getting Proxool to 1.0 in the next few months.
>
>[On that note, I will be posting some news about our future plans and
>priorities in the next few days. I want to be really clear about what
>work remains to be done.]
>
>- Bill
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Proxool-developer mailing list
>Pro...@li...
>https://lists.sourceforge.net/lists/listinfo/proxool-developer
>
>  
>

[Proxool-developer] Vote for Bertrand Renuart as a developer

[Bill H. <bi...@lo...>]

All,

Bertrand Renuart has kindly agreed to become a Proxool Developer. We
don't have an official procedure for adopting new developers but if
anyone feels minded to vote on whether he is accepted or not it will be
considered:

Bertrand has been an active contributor for the past few months and has
suggested some good patches. I think he'll be a very good addition to
the team. He should provide some necessary skills and motivation for
getting Proxool to 1.0 in the next few months.

[On that note, I will be posting some news about our future plans and
priorities in the next few days. I want to be really clear about what
work remains to be done.]

- Bill

Re: [Proxool-developer] ProxyFactory.buildConnection() - code review

[Bill H. <bi...@lo...>]

Bertrand,

On Thu, 2004-03-11 at 09:45, Bertrand Renuart wrote:

> I noticed the 'new ProxyConnection()' could throw an SQLException. If
> this happens, the *real* connection is not closed although it should
> probably be...

Well spotted.

> On the other hand, I had a look at why this constructor could throw
> the exception... And it can do so only if the 'realConnection' given
> as argument is null - there is a test at the end of the constructor...
> ==> Wondering when this could happen?

Agreed. It does seem a bit paranoid to test for null. The delegate
driver should either return a connection of throw an exception. 

> - if it is because we failed to obtain a connection from the
> DriverManager, then this should be tested in
> ProxyFactory.buildConnection (code snippet above);

Yep. I don't see why we don't do a test straight after asking for one. 

> - if it is because part of the ProxyConnection constructor will set
> the field to null if a problem occurs (don't think so), then ok, an
> SQLException could be thrown by the constructor - but then, the *real*
> connection should be released by the ProxyFactory...

That doesn't happen. The only reason why new ProxyConnection() will
throw an SQLException is if tthe real connection is null, and I think we
should test for that before getting to the stage of building the proxy
connection.

> (is it clear ?)

Absolutely.

> If the latter is true, then the ProxyFactory.buildConnection() should
> be modified as follows:
[snip]
>             try {
>                 // Ooops - unable to build the proxy - close the
> realConnection
>                 if(realConnection!=null) realConnection.close();
>             }
>             catch (SQLException e) {
>                 // Forget it - not much todo about it :(
>             }
[snip]

Well, the latter isn't true. But I still think this try/catch is worth
implementing. I don't think we need to catch SQLException (we may well
remove it from the new ProxyConnection signature) but we should
certainly catch RuntimeExceptions and make sure we close the real
connection. 

- Bill

[Proxool-developer] ProxyFactory.buildConnection() - code review

[Bertrand R. <ber...@mo...>]

Code snippet from ProxyFactory:=20
=20
   protected static ProxyConnection buildProxyConnection(...) throws
SQLException
   {
        Connection realConnection =3D null;
        final String url =3D connectionPool.getDefinition().getUrl();

        Properties info =3D
connectionPool.getDefinition().getDelegateProperties();
        realConnection =3D DriverManager.getConnection(url, info);

        Object delegate =3D Proxy.newProxyInstance(
                realConnection.getClass().getClassLoader(),
                realConnection.getClass().getInterfaces(),
                new ProxyConnection(realConnection, id, url, =
connectionPool,
status));

        return (ProxyConnection) Proxy.getInvocationHandler(delegate);
    }


I noticed the 'new ProxyConnection()' could throw an SQLException. If =
this
happens, the *real* connection is not closed although it should probably
be...

On the other hand, I had a look at why this constructor could throw the
exception... And it can do so only if the 'realConnection' given as =
argument
is null - there is a test at the end of the constructor... =3D=3D> =
Wondering
when this could happen?

- if it is because we failed to obtain a connection from the =
DriverManager,
then this should be tested in ProxyFactory.buildConnection (code snippet
above);

- if it is because part of the ProxyConnection constructor will set the
field to null if a problem occurs (don't think so), then ok, an =
SQLException
could be thrown by the constructor - but then, the *real* connection =
should
be released by the ProxyFactory...

(is it clear ?)


If the latter is true, then the ProxyFactory.buildConnection() should be
modified as follows:

    protected static ProxyConnection buildProxyConnection(long id,
ConnectionPool connectionPool, int status) throws SQLException {
        final String url =3D connectionPool.getDefinition().getUrl();

        // Build the *real* connection
        Properties info =3D
connectionPool.getDefinition().getDelegateProperties();
        Connection realConnection =3D DriverManager.getConnection(url, =
info);

      =20
        // Build a proxyConnection around it - release the *real* =
connection
if it fails
        ProxyConnection proxyConnection =3D null;
        try {
            proxyConnection =3D new ProxyConnection(realConnection, id, =
url,
connectionPool, status);
        }
        catch(SQLException se)
        {
            try {
                // Ooops - unable to build the proxy - close the
realConnection
                if(realConnection!=3Dnull) realConnection.close();
            }
            catch (SQLException e) {
                // Forget it - not much todo about it :(
            }
          =20
            throw se;
        }
      =20
      =20
        // Initialise our delegate
        Object delegate =3D Proxy.newProxyInstance(
                realConnection.getClass().getClassLoader(),
                realConnection.getClass().getInterfaces(),
                proxyConnection);

        return (ProxyConnection) Proxy.getInvocationHandler(delegate);
    }=20

RE: [Proxool-developer] Shutdown Hook

[Bertrand R. <ber...@mo...>]

Hi Carlos,

I don't understand clearly your problem...

Do you mean you can't register your own ShutdownHook because Proxool has
registered its one own before? Which sounds rather strange because
Runtime.addShutdownHook() allows for more than one hook to be =
registered...

Or your problem is because Proxool has run its Shutdown before your hook =
is
called? In other words, you want your code to be executed while Proxool =
is
still up and running...

Anyway, for the moment there is no way to deactivate proxool's hook - =
beside
hacking the code :(

-bertrand


> -----Original Message-----
> From: pro...@li...=20
> [mailto:pro...@li...] On=20
> Behalf Of ca...@ab...
> Sent: lundi 8 mars 2004 10:31
> To: pro...@li...
> Subject: [Proxool-developer] Shutdown Hook
>=20
>=20
> Hi all,
>=20
>     I=B4m developing an app that uses proxool. In this app I=20
> have created a shutdown hook to close all the open resources,=20
> but know I have a problem whith proxool because it captures=20
> the shutdown before my app, How can I change this?, Can I=20
> deactivate proxool=B4s hook?.
>=20
> Thanks.
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of GenToo technologies. Learn everything from=20
> fundamentals to system=20
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Proxool-developer mailing list Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
>=20

[Proxool-developer] Shutdown Hook

[<ca...@ab...>]

Hi all,

    I´m developing an app that uses proxool. In this app I have created a
shutdown hook to close all the open resources, but know I have a problem whith
proxool because it captures the shutdown before my app, How can I change this?,
Can I deactivate proxool´s hook?.

Thanks.