[infinispan-dev] Atomic Objects on top of Infinispan

[Galder Zamarreño]

Hi Pierre,

First of all, thanks a lot for your involvement and for implementing this interesting new functionality :)

I've made some comments below, but really, the best way to discuss this would be for you to send us a pull request and we use that as a way to comment on a line-per-line basis. Much easier :)

On Aug 19, 2013, at 7:11 PM, Pierre Sutra <pierre.sutra at unine.ch> wrote:

> Hello,
> 
> As part of the LEADS project (http://www.leads-project.eu), I
> implemented a factory of atomic objects on top of Infinispan. The code
> is available in the classes AtomicObject*.java stored in the directory
> https://github.com/otrack/Leads-infinispan/tree/master/core/src/main/java/org/infinispan/atomic
> of my Github clone of infinispan.

^ 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]

> The tests are written in the class
> AtomicObjectFactoryTest.java, available under
> core/src/test/java/org/infinispan/atomic. Besides, you may find below a
> simple code snippet:
> 
> AtomicObjectFactory factory = new AtomicObjectFactory(c1); // c1 is both
> synchronous and transactional
> Set set = (Set) factory.getOrCreateInstanceOf(HashSet.class, "k"); // k
> is the key to store the variable set inside the cache c1

^ 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,…

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...

> 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?

> 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.

> A call to some method of an object is serialized in a
> transaction consisting of a single put operation.

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.

> 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?

> 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]

> 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

> and is
> elastic (an atomic object supports on the fly the addition/removal of
> local and/or distant threads accessing it).
> 
> I hope that this work might interest you.

Cheers,

> 
> Best,
> Pierre

[1] https://docs.jboss.org/author/display/ISPN/Contributing+to+Infinispan#ContributingtoInfinispan-Topicbranches
[2] https://docs.jboss.org/author/display/ISPN/Plugging+Infinispan+With+User+Defined+Externalizers

> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org