distributed transactions

[Julian Reschke <ju...@gmx.de>]

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

R: distributed transactions

[Ancona Francesco <Fr...@siav.it>]

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:julian.reschke@gmx.de] 
Inviato: lunedì 18 aprile 2016 17:41
A: oak-dev@jackrabbit.apache.org
Cc: Diquigiovanni Simone <Si...@siav.it>; Morelli Alessandra <Al...@siav.it>
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.
************************************************************************************