5:33 a.m.
Hello,
^ It'll be easier for you to keep up with the latest master
changes in
upstream if you work on topic branches instead of your fork's master [1]
If I
understand correctly, this does not provide me with a copy on a
remote stable storage. Besides, I am not the only one to work on these
modifications.
^ Rather than pushing casting to users, it'd be better to do it
internally, i.e. with a definition like this: <T> T
getOrCreateInstanceOf(Class<T> clazz,…
It was not meant to be the final API,
and I will change this. (despite I
am not found of Java generics)
Also, getOrCreateInstanceOf name feels a bit verbose to me. Why not just call it
'create'? Alternatively, we already have code to create atomic maps in
AtomicMapLookup. We might wanna merge both into a single factory/lookup class. Not a
biggie though...
It is named getOrCreateInstanceOf because you may create a new object
but also, in case the object exists already in the system, receive a
consistent copy of it.
The two approaches of building maps are radically different, and they
will give radically different results. Nevertheless, I agree that
interfacing the two constructs with a single API would be of interest.
This is something I will eventually investigate.
> set.add("smthing"); // some call examples
> System.out.println(set.toString())
> set.addAll(set);
> factory.disposeInstanceOf(HashSet.class, "set", true); // to store the
> object in a persistent way
>
> The pattern I followed to implement this facility is the state machine
> replication approach. More precisely, the factory is built on top of the
> transactional facility of Infinispan.
^ Why do you need transactions? Can you just call put?
The approach I am following to implement linearizable (aka. atomic)
objects [1] is a variation of state machine replication [2]. At core,
state machine replication requires total order broadcast to propagate
the modifications - a property given by a push in transactional mode in
Infinispan.
> When the factory creates an
> object, it stores a local copy of the object and registers a proxy as a
> cache listener.
Hmmm, javassist based proxying. This needs some thought and consideration. I'm not a
huge expert on this topic, but we have Hibernate crew listening here which might be able
to provide feedback on how to best bridge over, since it's something they've been
doing since day one.
This approach seems to do a fairly good job and is both fast and
invisible to the user.
If you're just calling a single cache operation, don't see
the reason for a transaction. You still get notifications from other servers if something
fails. The only difference is lack of of rollback if something goes wrong in one of the
servers and it works fine in others. Not using transactions makes things work faster.
I could use a non-transactional cache, provided I have access to an
atomic broadcast primitive. For the moment, I did not find a
non-intrusive solution to this issue.
> When the call is
> de-serialized it is applied to the local copy, and in case the calling
> process was local, the result of the call is returned (this mechanism is
> implemented via a future object).
^ Why a future?
The result of the call is received via a call-back triggered by
modifications on the object's key.
> Notice that this implies that all the
> arguments of the methods of the object are serializable, as well as the
> object itself.
Serializable, or somehow marshallable… [2]
I will add this feature to the code
(e.g., by giving a marshaller object
to the factory).
> The current implementation supports the retrieval of
> persisted objects, an optimization mechanism for read operations,
^ Can you explain this read optimization in more detail? Why do you need it?
I'm also seeing a lot of marshalling in your code, which I don't understand why
you need it at all
The idea is to optimistically execute each operation locally
(marshalling here is employed to obtain a deep copy of the object). If
the operation does not modify the object, then it is safe to return the
result of its tentative execution to the caller. Notice here that,
strictly speaking, activating this feature makes the object not atomic
but sequentially consistent [3].
Best,
Pierre
[1] http://en.wikipedia.org/wiki/Linearizability
[2] http://en.wikipedia.org/wiki/State_machine_replication
[3] http://en.wikipedia.org/wiki/Sequential_consistency