To answer 1) it was initially designed that way because there are typically
multiple failure scenarios, points where you'd like to abort/rollback your
transaction. And quite often you've only got one point where you say that a
transaction is successful. So going for the most natural way of saying
thanks for that, the github help was most helpful
Meanwhile I realized why calling failure() on the child transaction flags
the root as failed, mainly because the child transaction cannot be reused
and thus we cannot know if it was retried or not, this being the difference
between child
Hi there,
yes, nested transactions are really using the most topmost transaction
for control, so your assessment if the commit semantics is right (I
think). Talked to Tobias about this, and maybe we could state this
more clearly in the docs. Got any good working we could change to?
Feel free to
Hey Peter,
Got any good working we could change to?
I'm not sure I understand what you mean, do you mean that if I have any good
text to add to the javadoc so it's stated more clearly ? or something
related to code instead? but if code, to do what?
I understand that they are using the topmost
Thanks John for the details!
As for the GIThub workflow:
http://www.eqqon.com/index.php/Collaborative_Github_Workflow
and http://help.github.com/
are good starting points!
Cheers,
/peter neubauer
GTalk: neubauer.peter
Skype peter.neubauer
Phone +46 704 106975
LinkedIn
Hello.
Are nested transaction supported?
From what I'm testing here, it looks like unless I specify .failure() on the
nested transaction, before it reaches .finish() the transaction is
considered to be successful (even if I didn't call .success() on it). Though
if I do call .failure() then the
6 matches
Mail list logo