"[EMAIL PROTECTED]" wrote : In anycase. What feature are you adding? | If it is generically useful, this could be added to the base implementation | rather than needing all this factory/plugins complication.
I belive that it is generically useful and would be appreciated by community. Basicly, added the next parameters to handle connection pool: 1. Aged timeout - the total amount of time which connection can be alive. After this period connections are removed from the pool. We are checking this period in two cases: when connection is returned to pool and by some external thread (IdleRemover). This timeout is different then IdleTimeout. 2. The conn-usage-limit - the limit of connection usage (total number of connection life circles "allocate-release"). 3. The reap-timeout - the time interval in seconds when connection must be checked by some external service. "[EMAIL PROTECTED]" wrote : IdleRemover is a static instance that runs a single remover thread for all pools. | | To override the implementation would require an IdleRemoveFactory | and a global configuration somewhere in jbossjca-service.xml | | Why do you need to change it? All it does it callback to the registered pool | on a timeout defined by the pool. There are several reasons: 1. IdleRemover defines waiting period for the thread. If we process additional timeouts by the same thread (like "aged timeout") currrent definition for the waiting period like t=min(IdleTimeout/2) is not suitable (for example aged timeout may be less than IdleTimeout). In this case is better to use additional independent parameter - "reap timeout" (how it's done for WebSphere). In this case waiting period calculated like min(reapTimeout). 2. Additional parameters can be encapsulated in PoolParams (or subclass of PP), but in case of subclassing of PoolParams we have to make correspondent casting in IdleRemover or overload a constructor. "[EMAIL PROTECTED]" wrote : I would be prepared to accept a modification that allows the internal pool | classname to be specified on the ManagedConnectionPool. | | In fact there are three configurations that are hardwired and need exposing | in -ds.xml for more advanced use cases: | | Code: | | Defines the ManagedConnectionPool implementation (default JBossManagedConnectionPool) | Defines the internal pool implementation (default InternalManagedConnectionPool) | Allows the connection manager implementation to be overridden | | In fact, allowing the ManagedConnectionPool to be overriden is probably too | broad brush when what is really required is the ability to specify the PoolingStrategy | class rather than using the short hand ByContainer, ByApplication, etc. | | Care to prototype these modifications? Some of them involve changes | to the stylesheet rather than the code. | It would be perfect. We were very close to idea to define InternalManagedConnection by name. "[EMAIL PROTECTED]" wrote : On your immediate problem, it seems to that what is really required is the ability | define a plugin for the remover logic in InternalManagedConnectionPool. | You are right. It would be additional room for extension. Only one complication is that "aged timeout" processing shoud be done in two cases: 1. By external thread for connections in the pool (IdleRemover). Required callback method modification. 2. While returning connections to the pool (returnConnection(ConnectionListener cl, boolean kill)) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3865958#3865958 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3865958 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
