Hi Phil,
that's the way how I propose to synchronize pools using proxies
without implementing synchronized wrapper classes, if you don't see
issues about it I can start committing it let you all reviewing.
Please let me know, have a nice day!!!
Simo
{{{
public static <T> ObjectPool<T> synchronizedPool(final ObjectPool<T> pool) {
return synchronizedObject(pool, ObjectPool.class);
}
public static <K,V> KeyedObjectPool<K,V> synchronizedPool(final
KeyedObjectPool<K,V> keyedPool) {
return synchronizedObject(keyedPool, KeyedObjectPool.class);
}
public static <T> PoolableObjectFactory<T>
synchronizedPoolableFactory(final PoolableObjectFactory<T> factory) {
return synchronizedObject(factory, PoolableObjectFactory.class);
}
public static <K,V> KeyedPoolableObjectFactory<K,V>
synchronizedPoolableFactory(final KeyedPoolableObjectFactory<K,V>
keyedFactory) {
return synchronizedObject(keyedFactory,
KeyedPoolableObjectFactory.class);
}
private static <T> T synchronizedObject(final T toBeSynchronized,
final Class<T> type) {
if (toBeSynchronized == null) {
throw new IllegalArgumentException("Object has to be
synchronized must not be null.");
}
/**
* Used to synchronize method declared on the pool/factory
interface only.
*/
final Set<Method> synchronizedMethods = new HashSet<Method>();
for (Method method : type.getDeclaredMethods()) {
synchronizedMethods.add(method);
}
return type.cast(Proxy.newProxyInstance(type.getClassLoader(),
new Class<?>[] { type },
new InvocationHandler() {
private final Object lock = new Object();
public Object invoke(Object proxy, Method method,
Object[] args) throws Throwable {
if (synchronizedMethods.contains(method)) {
synchronized (this.lock) {
return method.invoke(toBeSynchronized, args);
}
}
return method.invoke(toBeSynchronized, args);
}
}
));
}
}}}
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Dec 24, 2010 at 3:32 PM, Simone Tripodi
<simone.trip...@gmail.com> wrote:
> Hi Phil,
> thanks a lot for feedbacks and for mentoring, much more than appreciated.
> I take advantage to wish you all a Merry Christmas, all the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Dec 24, 2010 at 4:32 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
>> On Thu, Dec 23, 2010 at 2:28 AM, Simone Tripodi
>> <simone.trip...@gmail.com>wrote:
>>
>>> Hi Phil,
>>>
>>> >>
>>> >> org.apache.commons.pool2.impl
>>> >> |---- generic
>>> >> |---- reference
>>> >> |---- stack
>>> >>
>>> >> common stuff could be included directly under impl.
>>> >>
>>> >
>>> > What exactly would that be?
>>> >
>>>
>>> just realized that there are no common stuff shared by different kind of
>>> pool :P
>>>
>>> >
>>> > I was going to propose dropping the stack pools altogether. The
>>> LIFO/FIFO
>>> > config option in the generic pools makes them mostly irrelevant (i.e.,
>>> you
>>> > can get the same behavior with a suitably configured GOP / GKOP with much
>>> > more configurability)
>>> >
>>>
>>> I had the same feelings here, but felt a little shy on saying that.
>>>
>>
>> No reason for that :)
>>
>>
>>> You've my full support on this, I agree on dropping stack based pool
>>> implementations.
>>>
>>> Good. Lets do it.
>>
>>
>>> > I don't want to sound too conservative and I will certainly not stand in
>>> the
>>> > way of new / different pool implementations, but I would personally
>>> prefer
>>> > to keep the number of included pool impls as small as possible.
>>> >
>>>
>>> I propose a more democratic way, I mean, like you made us notice,
>>> keeping/adding the pool impl only if it makes sense to.
>>> I wouldn't think about the included pools in therms of "size" but
>>> rather in therms of "meaning"
>>>
>>
>> Agree this is completely up to the community and them who bring the
>> patches. The reason that I tend to be conservative is that more impls mean
>> more bugs, which makes fixing them all and getting releases out quickly
>> harder. Pooling code is tricky to maintain, so fewer pools with
>> less-exotic features might be better all around - not just in terms of
>> maintenance, but also approachability from the standpoint of users and
>> contributors.
>>
>>>
>>> > I think the first thing we need to do is to decide what implementations
>>> we
>>> > are going to a) keep or b) add for 2.0. I have been convinced that we
>>> need
>>> > to keep GKOP as well as GOP. As I said above, I would like to consider
>>> > dropping the stack-based pools. I think we should keep the
>>> reference-based
>>> > pool and I am open to the new ones you suggest, just don't have use cases
>>> > myself for them.
>>>
>>> I'm not ready to show use cases too, sorry :( But they can be added
>>> with a trivial refactory, moving the current SoftReferenceObjectPool
>>> implementation to an
>>>
>>> AbstractReferenceObjectPool<T, R extends Reference<T>> extends
>>> BaseObjectPool<T> implements ObjectPool<T>
>>>
>>> then in subclasses do the minimum. I can quickly provide a patch for it.
>>>
>>
>> I am OK with this as long as it does not complicate the code too much.
>>
>>>
>>> > There are quite a few impls buried in PoolUtils that might
>>> > make sense to pull out (or eliminate).
>>> >
>>>
>>> I just made a census (with proposals):
>>>
>>> * PoolableObjectFactoryAdaptor
>>> * KeyedPoolableObjectFactoryAdaptor
>>> * ObjectPoolAdaptor
>>> * KeyedObjectPoolAdaptor
>>>
>>> I propose to eliminate these adaptors,
>>
>>
>> That's the spirit - he he
>>
>>
>>> they implement a behavior that
>>> users can replicate with a trivial code and without build a
>>> pool/factory on top of an existing ones
>>>
>>> * CheckedObjectPool
>>> * CheckedKeyedObjectPool
>>>
>>> These can be eliminated too, having introduced the generics
>>>
>>
>> +1 - I think Gary may have mentioned this already. Lets get rid of them.
>>
>>>
>>> * ObjectPoolMinIdleTimerTask
>>> * KeyedObjectPoolMinIdleTimerTask
>>>
>>> I propose these pools can be pulled out and moved to a proper package
>>>
>>> I wonder if anyone uses these? I wonder also if it might be better to just
>> expose ensureMinIdle.
>>
>>
>>> * SynchronizedObjectPool
>>> * SynchronizedKeyedObjectPool
>>> * SynchronizedPoolableObjectFactory
>>> * SynchronizedKeyedPoolableObjectFactory
>>>
>>> These could be pulled out too, even if something suggests me that
>>> pools synchronization can be realized with just a Proxy, I'll do a
>>> little experiment to submit so you can evaluate.
>>>
>>
>> Interested in ideas on this. Here again, I am not sure how much use these
>> actually get.
>>
>>>
>>> > What might make sense is to replace "impl" with "instance" (or "object")
>>> and
>>> > "reference" (or "ref"). So you have o.a.c.p, o.a.c.p.instance,
>>> > o.a.c.p.reference.
>>> >
>>>
>>> sounds much better than keeping the intermediate "impl", I agree :)
>>>
>>> Should I have to write all these notes on the wiki and open issues
>>> before proceeding?
>>>
>>
>> I would say wait a bit to see if anyone has problems with above and if not,
>> go ahead and make the changes.
>>
>>
>>> Many thanks in advance, have a nice day!
>>>
>>
>> Thank you!
>>
>> Phil
>>
>>> Simo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
