"[EMAIL PROTECTED]" wrote : I still don't see why you need to change the
IdleRemover.
|
| If the aged timeout is less than the idle timeout, you pass that as the
interval.
| It just means it is going to make more frequent calls to removedTimeOut.
|
Right. But IdleRemover makes additional calculation:
private void internalRegisterPool(InternalManagedConnectionPool mcp, long
interval)
{
synchronized (pools)
{
pools.add(mcp);
if (interval > 1 && interval/2 < this.interval)
{
this.interval = interval/2;
}
...
}
I would prefer to change it a little by:
private void internalRegisterPool(InternalManagedConnectionPool mcp, long
newInterval)
{
synchronized (pools)
{
pools.add(mcp);
if (interval > 1 && newInterval < this.interval)
{
this.interval = newInterval;
}
...
}
Meaning of "interval" would be more straightforward here.
"[EMAIL PROTECTED]" wrote :
| There is no loss here since it just checks one connection (the oldest
unused)
| to see whether it timed out, or you have more complicated processing.
| It may check more with your policy.
|
| I'd suggest you identify a TimeoutPolicy that can be plugged into the
InternalManagedConnectionPool.PoolParams
| (with a default policy for when it is not specified - that is the current
default).
|
Ok. For Idle connections enough to check elements from FIFO by ".get(0)", but
for "aged connections" it is more complicated but may be encapsulated in
TimeoutPolicy.
"[EMAIL PROTECTED]" wrote :
| This would encapsulate:
| 1) The interval used when registerting with the idle remover
| 2) What happens at return connection (i.e. should it kill it)
| 3) What happens on the callback from the idle remover
| 4) What data (javabean object) needs storing in the ConnectionListener to
satisfy the policy
| Any others?
|
| Something like:
|
| | public interface ConnectionTimeoutPolicy
| | {
| | void setPoolParams(PoolParams pp); // invoked at pool startup after
construction
| | long getRemoverInterval(); // invoked at pool startup before
registering with idle remover
| | boolean isTimedOut(ConnectionListener cl); // invoked on each return
| | ArrayList /* connections to destroy */ removeTimedOut(Arraylist
connectionListeners); // invoked from the idle remover callback
| | Object initTimeOutParams(); // inserted into each ConnectionListener
| | }
| |
|
|
Some additions:
1. I would remove setPoolParams(PoolParams pp) from interface and add factory
method getConnectionPolicy(String classname, PoolParams pp);
in this case default implementation would be like:
public class DefaultConnectionTimeoutPolicy implements ConnectionTimeoutPolicy
{
protected DefaultConnectionTimeoutPolicy(){}
public ConnectionTimeoutPolicy getConnectionPolicy(String classname,
PoolParams){
ConnectionTimeoutPolicy ctp = null;
if(classname != null){
try{
ctp = class.byName(classname);
}
catch(){}
}
else if(ctp == null){
ctp = new Default...();
}
ctp.setPoolParams();
return ctp;
}
protected void setPoolParams(PoolParams pp){}
}
2. I would add long getInterval(); method to interface.
For default implementation it would be like:
public getInterval(){
return PoolParams.idleTimeout/2;
}
"[EMAIL PROTECTED]" wrote :
| The only issue is how you make it easily configurable through the stylesheet
| and maintain backwards compatibily for older configurations.
| i.e. we need somebody using the current configuration to be unaware
| of this change.
| How is your xslt :-)
|
| This gives you what you want and it is possible for somebody else to
override
| the behaviour in the future.
XSLT not a problem, but several additional things has been done:
1. InternalManagedConnectionPool has to be refactored (constructor,
returnConnection(), removeTimeout() and PoolParams inner class).
I would added protected accessors to some private fields to simlify future
subclassing.
2. I would separate JBossManagedConnectionPool class and inner BasePool tree.
3. Some new initialization parameters may be addded to subclass of
JBossManagedConnectionPool if we add accessor to "poolParams" field.
4. BaseConnectionManager.BaseConnectionEventListener
should contain reference to Object which encapsulate timeout parameters like:
{
private long lastUse;
private long firstUse; // Added to support aged timeout
private long timesUsed = 0; // Added to support usageLimit
}
4. ConnectionFactoryTemplate.xsl changes in this case would be trivial like:
<!-- template to generate the pool mbean -->
<xsl:template name="pool">
<xsl:param name="mcf-template">generic-mcf</xsl:param>
<depends optional-attribute-name="ManagedConnectionPool">
<!--embedded mbean-->
<mbean
code="org.jboss.resource.connectionmanager.ext.NewManagedConnectionPool"
name="jboss.jca:service=ManagedConnectionPool,name={jndi-name}"
display-name="Connection Pool for DataSource {jndi-name}">
....
<!-- new parameters -->
<xsl:choose>
<xsl:when test="timeout-policy-class-name">
<xsl:value-of select="timeout-policy-class-name"/>
</xsl:when>
<xsl:otherwise>
null
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="aged-timeout">
<xsl:value-of select="aged-timeout"/>
</xsl:when>
<xsl:otherwise>
0
</xsl:otherwise>
</xsl:choose>
....
Correspondent changes has to be added to .dtd
If user defines this properties in ds.xml -> will be used some new
ConnectionTimeoutPolicy,
if not - DefaultConnectionTimeoutPolicy (functionality will be transparent and
exactly the same as before.)
Agree? How we can proceed with this solution?
I am ready to prepare prototype for 1-2 days.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3866055#3866055
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3866055
-------------------------------------------------------
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
