Database monitoring and connection pooling

Thomas Segismont tsegismo at redhat.com
Wed May 29 14:31:58 UTC 2013


Thanks Elias for pointing this out. I created this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=968361

 From my point of view there is no reason for the abstract database 
plugin to ship a connection pool. Many drivers provide a connection pool 
backed datasource class. I think such classes should be used where 
possible to avoid loading an additional library.


Le 28/05/2013 21:41, Steve Millidge a écrit :
> In my experience the current base class can leak connections badly if
> used simply hence I did somethings different when I fixed the MySQL plugin.
>
> +1 from me for a connection pool.
>
> *From: *Elias Ross
> *Sent: *Tuesday, 28 May 2013 20:35
> *To: *rhq-devel at lists.fedorahosted.org
> *Reply To: *rhq-devel at lists.fedorahosted.org
> *Subject: *Database monitoring and connection pooling
>
>
> The database plugin does not use connection pooling. I think the idea
> is that the Resource (Oracle/MySQL/etc.) holds a single connection and
> provides it to sub-resources. Say if you are monitoring a database
> table or number of users logged in you call this API:
>
> public interface DatabaseComponent<T extends ResourceComponent<?>>
> extends ResourceComponent<T> {
> Connection getConnection();
> void removeConnection();
> }
>
> Problems arise with multiple threads. Are connections useable across
> multiple threads? Meaning, if an availability check runs and also a
> metric collection runs, both threads may be hitting the same
> connection. This should be okay in theory, but there are many
> potential pitfalls, including dealing with commit/rollback, resource
> leaking, etc.
>
> The other problem is, contrary to what the API implies, you would not
> want to close the connection by calling 'removeConnection', because
> what that would cause is interference with other threads' work. In
> practice (looking at the code), removeConnection is called when an
> error happens, not when done with running a query.
>
> The solution I suggest is:
> 1) Implement the generic database plugin using a database connection
> pool. BoneCP is my suggestion. It is very small and simple. I would
> simply hard-code some defaults in there and add some basic logging.
> 2) Deprecate 'removeConnection' or remove it entirely (API breakage)
> 3) Update the (Java) documentation.
> 4) Update mysql, oracle plugins to remove the connection once obtained
> through 'getConnection'.
>
> Thoughts?
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>



More information about the rhq-devel mailing list