10:36 a.m.
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(a)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...
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#Con...
[2]
https://docs.jboss.org/author/display/ISPN/Plugging+Infinispan+With+User+...
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org