commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] reorganizing pool2.impl package and new possible pool implementations
Date Sun, 26 Dec 2010 12:41:00 GMT
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.tripodi@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.steitz@gmail.com> wrote:
>> On Thu, Dec 23, 2010 at 2:28 AM, Simone Tripodi <simone.tripodi@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message