Yes, i know that we can manage in our application logic inconsistent situations, but we'd like to know the rational behind these intentional design constraint. With transaction it's obvious that coding should be easier.
Thanks in advance -----Messaggio originale----- Da: Julian Reschke [mailto:[email protected]] Inviato: lunedì 18 aprile 2016 17:41 A: [email protected] Cc: Diquigiovanni Simone <[email protected]>; Morelli Alessandra <[email protected]> Oggetto: distributed transactions On 2016-04-18 17:22, Ancona Francesco wrote: > I try explain the case. > > We know that OAK doesnt'support Transaction, so the following should > be the JCR implementation: > > http://www.day.com/specs/jcr/2.0/10_Writing.html > > When i use session write-methods, i can execute a sequence of session > methods (example add nodes) but only when i use save method i persist > the changes. > > Instead when i use Workspace-Write Methods (example > VersionManager.checkin, checkout, checkpoint, restore, restoreByLabel, > merge, cancelMerge, doneMerge, createActivity , removeActivity and > createConfiguration), for each action i persist on the workspace. > > So, imagine a use case in which i must create a version of a document > and save it in my repository in atomic way; if the first phase works > but the second one is KO, we have inconsistent data: the document has > a new version but is not saved. > > *Which kind of workaround do you suggest to solve this problem ?* > > Thanks in advance, > > best regards OK, so first of all this has *nothing* to do with the RDB persistence in particular; it applies to all persistence modes of OAK. Furthermore, I don't agree this is a "major" problem. Yes, there are certain sequences that can't be done atomically; this is intentional design constraint of Oak (of now). It's not entirely clear to me why this isn't something that application logic can't deal with. Best regards, Julian ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************
