Hi Marco!
> just for summarize a little our discussion: currently the implementation
> committed works exactly as Collections.syncronized* methodos.
si señor!
> The workaround to export the lock outside is this:
>
> ===
> GraphInvocationHandler<T> handler = new GraphInvocationHandler<T>(
> synchronizedMethods, checkedToBeSynchronized );
> Object proxy = newProxyInstance( type.getClassLoader(), new Class<?>[] { type
> }, handler );
> handler.lock = proxy;
> return type.cast( proxy );
> ===
> First of all we create the handler that utilize 'lock' variable to open the
> synchronized blocks and after the lock has been set whit the same proxy
> instance that will be returned.
>
I still haven't got where the workaround is and why the handler itself
cannot be used as lock object - given the fact the newProxyInstance()
creates an object != Handler is true, the only member of the proxy is
the handler itself.
A proxy class extends java.lang.reflect.Proxy and has an associated
invocation handler object to dispatch methods invocation. Under this
conditions, the only way to get the lock object from outside, is
accessing to the created handler.
So please point me to some doc I maybe don't know or overlooked - TIA
>> I though once again on this and maybe having a synchronized Graph
>> would be different than having a ConcurrentGraph, like
>> Collections.synchronizedMap() and ConcurrentHashMap,
>
> why [graph] is different from a Map or List data structure? Graph it self is
> a data structure, isn't it?
>
:| who said the opposite?!? read my tense as:
CommonsGraph#synchronize() : ConcurrentGraph (TBD) =
Collections.synchronizedMap() : ConcurrentHashMap
>
>> so my suggestion
>> is keeping the synchronized proxy as they are AND provide Concurrent*
>> version of actual graphs. I would implement these adapters in a proper
>> `concurrent` package. Does it make sense to you?
>
> Is sounds good, but I didn't understand very well your idea. What does it
> means implement an adapter?
>
implementing the object adapter pattern for a façade; for a first
spike, I wouldn't re-implement ConcurrentGraph from scratch but rather
adapting an existing one (it could maybe useful to make Concurrent
graphs provided by vendors)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
