commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18905] - Couldn't get connection (Jdbc2PoolDataSource)
Date Sun, 08 Jun 2003 08:12:49 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18905>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18905

Couldn't get connection (Jdbc2PoolDataSource)





------- Additional Comments From tagunov@motor.ru  2003-06-08 08:12 -------
Implementing

    getConnection( user, passwd )
    
is a complicated thing with a 
pooling
DataSource.

The difficulty is what to do in
the following 
situation:

1)

    getConnection( "foo", "bar" );
    
    The database allowes user "foo"
    
with password "bar"
    
2)

    The connection is returned to pool
    
3)    

    getConnection( 
"foo", "baz" );
    
What to do now?

Basically there are three options:

I)

   Use 
KeyedObjectPool and make the
   {user,passwd} the key.
   
II)

   Consider that a user may have 
only
   one correct password and refuse
   the second getConnection()
   
III)

   Always 
attempt to create a connection
   when a new password for a user is
   supplied. Keep tract of 
previously
   successfull passwords. (Last 100 for
   instance).
   
----

Clearly I) is not very 
good. We may
have 10 connectons ready for {"foo","bar"}
and we will still create a new one 
for
{"foo", "baz"}.

II) is very good, _if_ the assumption is
correct

III) has its own 
drawbacks: we will create
connections even when we do not need to.


-----

Also III) will 
require a rewrite to KeyedObjectPool,
but this is an implementation issue.

-----

It looks 
that before fixing JDBC2DataSource we
should decide which of I), II), III) we want.

-----

As 
additional remarks: the current code in
JDBC2DataSource has caused some surprise 
from
me:

a) why use the master HashMap and an instaceId?
   Just to implement closeAll()?
   

   But that is done easier: have a pool in instance
   variable, like m_pool and chain all 
instance
   together via a LinkedList() or just via
   m_next pointer.
   
b) why an ordianry, not 
keyed, ObjectPool is sometimes
   created?  If we're enforcing (username, password)
   check, it 
is impossible to implement also
   getConnection() in the same DataSource!

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message