[jira] [Resolved] (POOL-140) Rethink synchronisation strategy
[ https://issues.apache.org/jira/browse/POOL-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-140. -- Resolution: Fixed Both these issues have been addressed in the redesign and re-factoring that is part of Pool2. Rethink synchronisation strategy Key: POOL-140 URL: https://issues.apache.org/jira/browse/POOL-140 Project: Commons Pool Issue Type: Task Reporter: Sebb Fix For: 2.0 Holding place for items related to synch. that need to be addressed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-177) GenericKeyedObjectPoolFactory and GenericObjectPoolFactory to share a common superclass
[ https://issues.apache.org/jira/browse/POOL-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-177. -- Resolution: Won't Fix Having restarted the pool2 re-factoring using dbcp2 as a reality check for what we do with pool2, GenericObjectPoolFactory and GenericKeyedObjectPoolFactory have nothing in common that could usefully be pulled up into a base class. GenericKeyedObjectPoolFactory and GenericObjectPoolFactory to share a common superclass --- Key: POOL-177 URL: https://issues.apache.org/jira/browse/POOL-177 Project: Commons Pool Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Gary D. Gregory Fix For: 2.0 Attachments: POOL-177.diff, POOL-177.diff I see now in trunk that GenericKeyedObjectPoolConfig extends GenericObjectPoolConfig, which I like. It seems that the next step would be for GenericKeyedObjectPoolFactory and GenericObjectPoolFactory to share a common superclass. To see what I mean, look at the patch in this ticket. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-103) Tracing borrowed objects
[
https://issues.apache.org/jira/browse/POOL-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-103.
--
Resolution: Fixed
The re-factoring in pool2 has added checks that throw an exception if:
- an object is returned to the pool that wasn't borrowed from the pool
- an object is returned to the pool twice
Tracing borrowed objects
Key: POOL-103
URL: https://issues.apache.org/jira/browse/POOL-103
Project: Commons Pool
Issue Type: Improvement
Affects Versions: 1.3
Reporter: immars
Fix For: 2.0
Once an object is borrowed from a GenericObjectPool, it could be
returnObject()-ed once or invalidateObject()-ed once, but not both.
However, in my working environment, people often tend to write code like this:
MyObject mo = null;
try{
mo = myPool.borrowObject();
}catch(Exception e){
myPool.destoryObject(mo);
}finally{
if(mo != null){
myPool.returnObject(mo);
}
}
In this case, _numActive in GenericObjectPool would be decreased twice once
an Exception is thrown.
So eachtime I use GenericObjectPool, I always wrap the pool like this:
class MyPool extends GenericObjectPool{
HashSet borrowed = new HashSet();
public synchronized Object borrowObject() throws Exception {
Object ret = null;
ret = super.borrowObject();
if (ret != null) {
borrowed.add(ret);
}
return ret;
}
public synchronized void invalidateObject(MyObject mo) {
if(borrowed.contains(mo)){
borrowed.remove(mo);
super.invalidateObject(mo);
}
}
public synchronized void returnObject(Object obj) throws Exception {
if (borrowed.contains(obj)) {
borrowed.remove(obj);
super.returnObject(obj);
}
}
}
So the inner counter _numActive would not get corrupted due to incorrect call
to returnObject() or invalidateObject().
I wonder if this feature could be included into the mighty commons-pool
library to make this class completely FOOL proof :)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13061618#comment-13061618 ] Max Tardiveau commented on JEXL-113: Hi Henri, thanks for following up on this. My personal preference would be for an option to select between 1, 2 and the current behavior, but I don't know if that's just me? We have a workaround for now, but if we had this option, we could throw away the workaround, so it would be quite useful. In case you're curious, we need to determine dependencies from an expression -- which objects and attributes are accessed in the expression. We currently evaluate the expression and we use a custom context object that returns special objects that keep track of what gets accessed. It's not horrible, but it is more complicated than I'd like it to be. Allow me to reiterate that this is a *very* useful library, and that we very much appreciate it. Thanks again, -- Max Dot notation behaves unexpectedly with null values -- Key: JEXL-113 URL: https://issues.apache.org/jira/browse/JEXL-113 Project: Commons JEXL Issue Type: Bug Affects Versions: 2.0.1 Environment: JDK 1.6 Reporter: Max Tardiveau When a variable of the form a.b is evaluated, the context is asked first for the value of a. That value is then asked for the value of b. So far, so good: this is exactly what you'd expect from the dot operator. But if the value of b is null, the context is then asked for the value of a.b, in other words the dot operator is ignored and a.b is considered to be a single variable. This is at best confusing. Granted, this can be avoided with the a['b'] notation, but that's clumsy. I assume this is an attempt to support both the dot operator and ant-style variables. I don't think you can have both and remain sane. Suggestion: either document this behavior, or make it an option. My vote would be to just use the value returned, even if it's null. Either dot is an operator, or it's not. Perhaps make that configurable? Thanks! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
