You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Ancona Francesco <Fr...@siav.it> on 2016/04/14 17:24:57 UTC
critical question about oak: RDBMS and distributed transaction
Hi,
thanks for rdbms help. I managed to run my application also with postgres and Oracle. My wrong has been that default installation doesn't work; we need to set another collation. (in detail collation C)
Can i suggest to add these details to the documentation ?
Now we have an other problem.
We found that distributed transactions are not supported in OAK. This could be a problem when we need to aggregate different kind of services (our database and ecm services): so our data could be not choerent in specific situations.
Besides we noticed that there is a major issue opened in 2013 but not closed.
So i point out 3 question
1. Is there a roadmap or an indicative date to solve this issue?
2. Which kind of workaround do you suggest to solve the problem now ?
3. Do you know if adobe oak built-in product has implemented the distributed transactions ?
Thanks in advance
Best regards
[cid:image003.png@01D19672.94AA1E30]
Francesco Ancona | Software Dev. Dept. (SP) - Software Architect
tel. +39 049 8979797 | fax +39 049 8978800 | cel. +39 3299060325
e-mail: francesco.ancona@siav.it | www.siav.it
I contenuti di questa e-mail e dei suoi allegati sono confidenziali e riservati esclusivamente ai destinatari.
L'utilizzo per qualunque fine del presente messaggio e degli allegati così come la relativa divulgazione senza l'autorizzazione del mittente sono vietati.
Se avete ricevuto questa e-mail per errore, vi preghiamo di distruggerla e di comunicarcelo.
I dati personali sono trattati esclusivamente per le finalità della presente comunicazione in conformità con la legislazione vigente (D.lgs. 196/2003 "Codice Privacy").
Per informazioni: SIAV S.p.A. - siav@siav.it - 049 8979797
The contents of this e-mail and its attachments are confidential and reserved exclusively to the recipients.
The use for any purpose of this message and attachments as well as its disclosure without the consent of the sender is prohibited.
If you have received this email in error, please destroy it and notify us.
Personal data shall be processed solely for the purposes of this notice in accordance with current legislation (Legislative Decree no. 196/2003 "Code").
For more information: SIAV S.p.A. - siav@siav.it - 049 8979797
R: distributed transactions
Posted by 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.
************************************************************************************
distributed transactions
Posted by 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: critical question about oak: RDBMS and distributed transaction
Posted by Ancona Francesco <Fr...@siav.it>.
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
[cid:image003.jpg@01D19996.DE408710]
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
-----Messaggio originale-----
Da: Julian Reschke [mailto:julian.reschke@gmx.de]
Inviato: giovedì 14 aprile 2016 18:05
A: oak-dev@jackrabbit.apache.org
Cc: Diquigiovanni Simone <Si...@siav.it>; Morelli Alessandra <Al...@siav.it>
Oggetto: Re: critical question about oak: RDBMS and distributed transaction
On 2016-04-14 17:24, Ancona Francesco wrote:
> Hi,
>
> thanks for rdbms help. I managed to run my application also with
> postgres and Oracle. My wrong has been that default installation
> doesn't work; we need to set another collation. (in detail collation
> C)
>
> Can i suggest to add these details to the documentation ?
The only documentation right now is in RDBDocumentStore's javadoc, and that does mention it.
> Now we have an other problem.
>
> We found that distributed transactions are not supported in OAK. This
> could be a problem when we need to aggregate different kind of
> services (our database and ecm services): so our data could be not
> choerent in specific situations.
>
> Besides we noticed that there is a major issue opened in 2013 but not
> closed.
Specifically?
> So i point out 3 question
>
> 1.Is there a roadmap or an indicative date to solve this issue?
>
> 2.Which kind of workaround do you suggest to solve the problem now ?
>
> 3.Do you know if adobe oak built-in product has implemented the
> distributed transactions ?
AFAIU, Oak wasn't designed with distributed transactions in mind, nor is it currently used that way. I'm not aware of any plans to change that...
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.
************************************************************************************
Re: critical question about oak: RDBMS and distributed transaction
Posted by Julian Reschke <ju...@gmx.de>.
On 2016-04-14 17:24, Ancona Francesco wrote:
> Hi,
>
> thanks for rdbms help. I managed to run my application also with
> postgres and Oracle. My wrong has been that default installation doesn’t
> work; we need to set another collation. (in detail collation C)
>
> Can i suggest to add these details to the documentation ?
The only documentation right now is in RDBDocumentStore's javadoc, and
that does mention it.
> Now we have an other problem.
>
> We found that distributed transactions are not supported in OAK. This
> could be a problem when we need to aggregate different kind of services
> (our database and ecm services): so our data could be not choerent in
> specific situations.
>
> Besides we noticed that there is a major issue opened in 2013 but not
> closed.
Specifically?
> So i point out 3 question
>
> 1.Is there a roadmap or an indicative date to solve this issue?
>
> 2.Which kind of workaround do you suggest to solve the problem now ?
>
> 3.Do you know if adobe oak built-in product has implemented the
> distributed transactions ?
AFAIU, Oak wasn't designed with distributed transactions in mind, nor is
it currently used that way. I'm not aware of any plans to change that...
Best regards, Julian