Hi there, I'm trying to accomplish the following: I want to enter savepoints and be able to either commit or rollback to these savepoints. After reading some documentation and finding some info here on the forum, I tried the following to see if it actually works (which it doesn't): I call a java action from my microflow where I try to commit my stuff this way by overriding the save button with a microflow. IContext ct = this.getContext().getSession().createContext(); ct.startTransaction(); ct.endTransaction(); Now, according to my understanding, this should commit my object. But obviously I'm missing something here... Eventually, the endTransaction should be performed from some other microflow, but for now I'd just like to see one object being committed at all. EDIT: just popped my mind: might it have to do with using the simple development database instead of a real one like postgre? It that is the case I might need to wear my STUPID button today...
3 answers

Looks like it should work to me. But I don't see the code where you are committing, are you actually using your newly created transaction to commit your object or execute some action? And what is the behavior you're actually seeing? And the built-in database is a bit poor in terms of transactions compared to postgresql but I'd expect this to work.

Update according to your new answer:

There is a difference between committing a transaction and committing an entity. I suppose you could say the naming for committing an entity is not entirely correct, it should just be called save or something. But after instantiating an entity you still have to save/commit it before it shows up in the database, it's not done automatically by committing the transaction it's in. You can make your own context/transaction in order to do your own transaction handling but then you need to instantiate that entity using your newly created context and you still need to commit it explicitly.

To be honest, I think you should just use the rollback mechanism in microflows, implementing this yourself would get enormously complex. Also it sounds like what you want to achieve is possible by just using rollbacks in microflows. But if you're dead set on doing it like you have in mind, I guess you'll need some way of identifying contexts in a static map in Java and then re-use those contexts between different calls to a java action.


Hi Bas,

I thought the endTransaction did the committing? I have this from the documentation: "Commit the transaction, this will end this transaction or remove a save point from the queue if the transaction is nested". So I guess if you think I am missing the committing that's where I misunderstood this...

The behaviour I see is that I get an empty context and that's it. Nothing happens.

Just out of curiosity, how would I keep track of my newly created context? The scenario I need is something like this and how I think it works (correct me if I'm wrong):

  • I have an object and I override the save button with a microflow where I create a context in java and call a startTransaction on the newly created context

  • I create another object and want to add this to the same context I created earlier (not sure how, with an identifier or something like that?)

  • repeat the previous step x times

  • I call another microflow which in it's turn calls a java action, pass the context (not sure how,because not sure how to keep track of created contexts trough the application) and call an endTransaction (which in my understanding commits everything and removes savepoints, but guess that's not the case), which commits all objects in the given context OR I call a rollback on the given context

Any thoughts on this?


Hi Robin,

Got you on the phone to discuss the matter, but to enable others to think with us I put it on the forum.

When I read the API documentation I think your solution of creating just one JAVA activity to do the trick will not work because *nothing happens between the start and the end of the transaction!. I expect the solution should be:

1) Create an JAVA activity that creates a context: Context ct = this.getContext().getSession().createContext();

2) Create another JAVA activity that starts a transaction: ct.startTransaction();

3) Create a third JAVA activity that ends a transaction: ct.endTransaction();

4) Create a microflow with the following sequence of actions: - JAVA action 1 - JAVA action 2 - create some objects - JAVA action 3

I expect the objects will now be committed within the context. Anyone agrees/disagrees?