Persistence plugin for deuce

[sstlaurent]

Hi,

i would like to make a persistence plugin for deuce. I'll explain my
plan. Can you roughly tell me if its possible to do it before i spend
too many days on it. I'm asking because i believe that someone here
has a deep understanding of the project.

the goal : persist transaction origin method call with its class and
its parameters in Command object. The data-store is made incrementally
from Command object that are reapplied upon system restart with the
help of a Resolver that get the vm object instances from serialized
ones.

So i need these data :
transactionOriginClassInstance;
transactionOriginObjectInstance;
transactionOriginMethodName;
transactionOriginMethodParameters;

It is possible to gather these data on transaction start.

Thanks

[Guy Korland]

Yes it's possible to add to the Context.init() this info.

Can you please define the API change more specific?

Notice that a transaction can span between many object and many classes. 

Guy

--
Guy Korland

[sstlaurent]

Heres my specifications.

Deuce api modification draft

Goal : Provide one external handler to listen to the course of the
transaction.

we define a Method class that hold all informations we need on origin
method. I added getAnnotations() method because i want to have the
flexibility to allow other annotations that the handler can use (like
@Persist)

class Method {

/* return method name */
public String getName();

/* return method parameters values or an empty array if none */
public Object[] getParameters();

/* return run time annotations or an empty array */
public Annotation[] getAnnotations();

}

we define a TransactionEvent class

class TransactionEvent {

public static enum Type {
INIT, COMMIT, ROLLBACK, RETRY,

/* HOOK to allow, just before commiting, an external agent to do
something that if throws an exception will rollback the transaction.
*/
HOOK
};

public Type getType();
public Method getOriginMethod();
/* return the origin object (a class if method call was static) */
public Object getOriginObject();

}

we define a TransactionEventHandler interface

interface TransactionEventHandler {

/* called after event in Deuce */
void handle(TransactionEvent event);

}

we hook the TransactionEventHandler to the Deuce api via System
properties, the same way we hook transaction manager (lsa, tl2, ...)

I made it more generic because i think that, with my persistence
implementation, it would not be possible to persist correctly all type
of transaction and that persistence would not be achieved by Deuce
itself. So this api modification can serve more purposes.

steeve

On 1 nov, 06:53, Guy Korland <gkorl...@gmail.com> wrote:
> Yes it's possible to add to the Context.init() this info.
> Can you please define the API change more specific?
> Notice that a transaction can span between many object and many classes.
>
> Guy
>

[Guy Korland]

Hi Steeve,

This can be done and I'll be glade to add it to Deuce.

But, I can't understand how are you going to replay all the other operations that were done not under transaction.

Guy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Deuce-STM developers" group.
To post to this group, send email to deuce-stm-...@googlegroups.com
To unsubscribe from this group, send email to deuce-stm-develo...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/deuce-stm-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

--
Guy Korland

[sstlaurent]

Hi Guy,

I'm glad that it is possible.

We wont be able to replay operations that were not under transaction.

Before finding Deuce, i was looking for a a persistence framework that
work without sql and that is simple. I look at Space4j among all i
found, which is simple but it doesn't really support transactions and
programmer need to wrap all their write operations in a Command
wrapper class.

Deuce is about transactions and programmers cant ask for simpler and
faster api (@Atomic) !
So programmers will still need to set under a transaction every
operations that modify the Space (like database but in memory), but
will benefit from Deuce advantage.

However i know this may not be the best for Deuce as my api will
certainly impact performance.

For now my ideas are still drafts, but as it is possible, i'll give it
a try.

Thank you

Steeve

On 14 nov, 17:28, Guy Korland <gkorl...@gmail.com> wrote:
> Hi Steeve,
>
> This can be done and I'll be glade to add it to Deuce.
> But, I can't understand how are you going to replay all the other operations
> that were done not under transaction.
>
> Guy
>

> > deuce-stm-develo...@googlegroups.com<deuce-stm-developers%2Bunsu...@googlegroups.com>

[Stefano Bagnara]

On 15 Nov, 05:12, sstlaurent <steeve.stlaur...@gmail.com> wrote:
> We wont be able to replay operations that were not under transaction.

Maybe you want to look also to Javaflow:
http://commons.apache.org/sandbox/javaflow/

I played a bit with it and the asm version is stable enough.

Javaflow have a much bigger overhead because it requires weaving all
of the classes included in the stack of the suspension point, but its
job is tracking all local fields/vars status in the current stack
operation, be able to persist them and restart later.

Stefano